On Tue, Jan 10, 2012 at 4:17 AM, MinRK <[email protected]> wrote: > > > On Mon, Jan 9, 2012 at 23:46, Martin Lucina <[email protected]> wrote: >> >> 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. > > > 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 <[email protected]> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
