[zeromq-dev] Proposal for libzmq maintenance

MinRK benjaminrk at gmail.com
Tue Jan 10 13:17:51 CET 2012

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

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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120110/ed20c0f2/attachment.htm>

More information about the zeromq-dev mailing list