[Zope-dev] Supporting interworking with repository branches on github

[Laurence Rowe]

On 24 November 2011 07:58, Wichert Akkerman <wichert at wiggy.net> wrote:
> On 11/24/2011 01:29 AM, Florian Friesdorf wrote:
>> On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver<tseaver at palladion.com>  wrote:
>>> Second, it is already feasible to work with modern VCSes against the
>>> existing SVN repository:  I've been doing it with bzr for literally years
>>> now;  I know of lots of documentation on using git against SVN as well. Of
>>> course, Github is more than a VCS, but its main advantage over other
>>> solutions lies in being able to accept casual contributions from non-core
>>> developers, which is hardly in scope for the early phases of the Zope4
>>> effort.
>> github enables a peer review process: while everybody who signed the
>> plone committer agreement could just commit to the plone repo, we do
>> pull-requests and somebody else with commit rights checks the request
>> and merges.
>
> We've never had a problem with peer review before. People review the
> commit lists which receive all commits with full diffs and react if they
> see something off. That is a very well working peer review system. I
> don't see that improving with github; in fact I see it becoming worse:
> commit emails no longer get diffs at all, and people are less likely to
> look at a webinterface for a quick review than they are to take a quick
> look at an email. The move from Plone to github certainly made me stop
> all review work, where I reviewed all commits to core code before.

I'm not sure I agree with that, it's certainly been an issue in CMF
for instance. Where we really miss out is that only a fairly small
group of people feel confident enough to commit their changes, and as
a group we do a poor job of encouraging new contributors as patches
are often left in the bug tracker. I certainly find it much easier to
review a pull request and click merge from the github interface
(leaving it to Jenkins to validate that the tests continue to pass.)
For the long term health of the project this is vital, we're not
replacing the developers we're losing.

It certainly shouldn't be that difficult to produce our own emails
with full changesets for Plone, it just requires someone who misses
them to pick it up.

Laurence