On Mon, 9 Jan 2012 23:20:01 -0600 Pieter Hintjens <[email protected]> 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 <[email protected]> _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
