it seems that Contributing.md should go to .github as well, @mattock?
Пт, 6 янв. 2017 г. в 21:06, Илья Шипицин <chipits...@gmail.com>:
> 2017-01-06 15:52 GMT+03:00 David Sommerseth <
> open...@sf.lists.topphemmelig.net>:
>
> On 06/01/17 09:18, Илья Шипицин wrote:
>
>
> > Hello,
>
>
> >
>
>
> > https://github.com/OpenVPN/openvpn/pull/77
>
>
> >
>
>
> > I'm not sure about exact text (I need help from you),
>
>
> > the idea behind those changes is to point developers who use regular
>
>
> > github workflow to a proper procedures (maybe there're pages on wiki ?
>
>
> > @mattock ?)
>
>
> >
>
>
> > it will help to not lose PRs and will probably save time of current
>
>
> > developers
>
>
>
>
>
> Two questions:
>
>
>
>
>
> 1) Can you explain what those .github/ files does?
>
>
> those files are mark down templates for new PRs and new issues.
> when someone open new PR, he sees such a template
>
> https://github.com/blog/2111-issue-and-pull-request-templates
>
>
>
>
>
>
>
> 2) Can you please elaborate *how* this will save us developers time?
>
>
> new developers will see guide how to use PRs and how to contribute. it
> will save developers time to explain those things to every new developer
> who followed github workflow (fork and PR)
>
>
>
>
>
>
>
> As we do have public reviews on a distributed channel (which is the
>
>
> mailing list [0]), I would dare to say we have a very efficient way of
>
>
> handling that process.
>
>
>
>
>
> - Patch(es) arrives the mailing list
>
>
> - Patch(es) gets reviewed, with feedback, and finally an ACK
>
>
> - Gert or I download the mail(s) in our mail program (including
>
>
> headers, fairly simple with mutt or alpline, not even much
>
>
> complicated in Thunderbird)
>
>
> - We run our 'git ack-am' [1] script which takes the mail file and the
>
>
> a nick of the person(s) giving an ACK ... which generates the "PATCH
>
>
> applied" mails automatically.
>
>
> - We push the git out the git trees.
>
>
>
>
>
> The GitHub PRs are actually not giving us developers much benefits. For
>
>
> the review process of larger patches, it can have some benefits for a
>
>
> more smooth discussion on individual patch lines. But once the patches
>
>
> are ready for final ACK, the mailing list approach is much more
>
>
> efficient for us, as we want to keep references to final discussions
>
>
> decentralized.
>
>
>
>
>
>
>
>
> [0] We don't trust that GitHub will be present forever and our
>
>
> mailing lists are archived several places, where the Message-ID is
>
>
> unique for each mail - regardless of mail archive hosting.
>
>
> [1] <https://gitlab.com/dazo/misc-git-tools/tree/master>
>
>
>
>
>
>
>
>
> --
>
>
> kind regards,
>
>
>
>
>
> David Sommerseth
>
>
> OpenVPN Technologies, Inc
>
>
>
>
>
>
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
