[zeromq-dev] Proposal for libzmq maintenance

[Brian Granger]

On Tue, Jan 10, 2012 at 4:17 AM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Mon, Jan 9, 2012 at 23:46, Martin Lucina <martin at lucina.net> wrote:
>>
>> On Mon, 9 Jan 2012 23:20:01 -0600
>> Pieter Hintjens <ph at imatix.com> wrote:
>>
>> > [snip]
>> > > It would be good to see "pull request" explicity defined as "an e-mail
>> > > sent to the zeromq-dev mailing list by the repository owner, asking
>> > > the
>> > > maintainers to pull from git://.../some-branch".
>> >
>> > Automatically. There's no benefit in forcing this to be manual, and
>> > there are risks. People can also subscribe separately to pull request
>> > emails.
>>
>> Doing this automatically mandates that contributors must use Github for
>> creating pull requests. That would be bad, and that is what I am
>> arguing against.
>>
>>
>> What specific risks do you see in sending an email manually?
>>
>>
>> > > Further, pull requests created on Github but *not* also sent to the
>> > > mailing list must be ignored by the maintainers, and this would be
>> > > prominently documented.
>> >
>> > Having used pull requests for some time now, my preference is to have
>> > them announced and discussed unavoidably, and then deleted if they
>> > don't come up to scratch. Otherwise you get an accumulation of old
>> > pull requests. A pull request becomes stale rapidly, it has to be
>> > accepted or deleted within a few days depending on the rate of change.
>>
>> I think we're in agreement here, but see below.
>>
>>
>> > > Rationale: This is needed to keep the process of accepting new changes
>> > > into master transparent to all interested parties (maintainers,
>> > > developers, users, lurkers, ...) and to avoid fragmenting the
>> > > discussion
>> > > or code review.
>> >
>> > Indeed. We'll hook up github to email the list automatically. IMO the
>> > same should eventually happen for new issues (not comments on issues).
>>
>> I would be wary of directing too much automated traffic to the main
>> mailing list; JIRA is far too chatty to ask that everyone read those
>> emails. What could be done for issues is creating a separate
>> zeromq-bugs list that gets everything from JIRA for those who want to
>> follow that.
>>
>> > > This doesn't stop anyone from using Github or other Web 3.0 coolness
>> > > to
>> > > create pull requests, but it does ensure that everyone else is kept in
>> > > the loop on any discussion while not being forced to use the same Web
>> > > 3.0 coolness.
>> >
>> > Personally, after trying all the options, I'm unwilling to apply
>> > patches by any other means except pull requests and quite willing to
>> > argue this one. The advantages so far outweigh the philosophical
>> > objections.
>>
>> You misunderstood what I wrote; I'm not arguing against using pull
>> requests, I'm arguing against *mandating* the Github *interface* to pull
>> requests.  The Github stuff is just a wrapper that (AFAIK) creates a
>>
>> branch for each pull request.
>
>
> I could be misreading, but it's actually thinner than it sounds like you are
> describing - GitHub does not create any branches.  You simply request that
> one of your branches be pulled into another (of yours or anyone else's).
>  The PR remains up to date with any changes you make to your branch until it
> is merged.  The GitHub stuff is just a view of the changes that would result
> from merging at any given point.
>
>>
>>
>> What I'm proposing is that a pull request is a *request sent by e-mail
>> by the requester* to the zeromq-dev list, asking that the changes staged
>> on branch "xyz_feature" of the repository found at "git://...." be
>> pulled into libzmq master. That's all.
>>
>> From the POV of Github contributors, this means the additional step of
>> sending an email with said text to zeromq-dev. For anyone else, that is
>> what they would be doing anyway.
>>
>>
>> From the POV of the maintainer processing the pull request, the process
>> is identical in both cases - "git pull git://host/repo/branch".
>>
>> If for some reason you want to be extra nice to Github users then by
>> all means figure out a way to hook up sending notifications of
>> Github-created pull requests to the mailing list but I think it's just
>> extra work with no real benefit, plus you run the risk of fragmenting
>> discussion about the content of the pull request since people *will*
>> comment using the Github interface, and we don't want that.
>
>
> I believe I am outvoted by those with philosophical objections to GitHub,
> but every time I see one of these workflow update emails I hope that zeromq
> is finally going to use GitHub for PRs and review instead of the
> mailing-list.  From our experience after we moved IPython to GitHub,
> contributions have simply exploded, from brand new contributors and core
> devs alike, and it's the GitHub PR and review tools that are largely
> responsible for the productivity of core devs and enthusiasm of new
> contributors.  I imagine that using GitHub would actually exclude *fewer*
> potential contributors than requiring that review take place on the
> mailing-list.

I heartily agree with Min on this one.  We use a pure github PR
approach on a number of different projects and it has radically
transformed the contributions we get in a number of important ways:

* We are getting many more contributions from many more people.  It
has been wonderfully insane - a litteral explosion of activity.
* We (those reviewing code, running tests and merging) are able to
review more contributions and keep up with things.
* The quality of code review has gone up.  The nice UI that github has
for discussions and line-by-line comments reduces the barrier for code
review and people are more willing to help out.
* Github PRs provide a fantastic public record of everything that
happens.  The integration with branches, showing nicely formatted
diffs is leaps and bounds better than a pure email based approach.

Cheers,

Brian

> Feel free to ignore my pro-GitHub propaganda. I promise they don't pay me -
> I just benefit a great deal from their tools, and would love to see zeromq
> do the same.
>
> -MinRK
>
>>
>>
>> Am I making sense now?
>>
>> -mato
>> --
>> Martin Lucina <martin at lucina.net>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com