[zeromq-dev] Proposal for libzmq maintenance

[Martin Lucina]

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.

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.

Am I making sense now?

-mato
-- 
Martin Lucina <martin at lucina.net>