On Sep 1, 2011, at 9:23 AM, Chris Lalancette wrote:
As the old-timer around here, I will say that I do like the post
patch and
ACK process. It is familiar in the open-source world, it is easy to go to one
place to see all of the proposed patches, and I think it keeps code quality up.
What I'm most worried about with the github model is pull requests that go in
without everyone being able to see them.
My concern has always been that the patches dilute people's mailboxes. I'd rather
not have to chose between possibly missing a relevant patch because my filters didn't
catch it or wading through patches I don't care about for the ones I do and possibly
still missing it. With GitHub, I'll get notified about the projects I'm a member
of without having to wade or filter and I have the ability to syndicate pull requests,
commits, etc on projects I'm just interested in.
GitHub provides really nice tools for discussing pull requests and commits, allowing you
to annotate commits and diffs by line if you want. Couple that with being able to directly
pull the branch from which the pull requests originate instead of having to branch and
apply locally and I think you'll find more review participation with higher quality of
output at the end of the day.
As has been pointed out elsewhere in the thread, the model expounded
upon in
the above link is somewhat a description of our process, though it is slightly
different. Actually, what is really interesting is that it basically describes
our process when we had the master/next split; the master branch was always
"deployable", but it turned out that it had exactly zero consumers. I
don't
think anyone wants to go back to that.
I didn't take away from that post that the author was advocating the git-flow branch
model that the master/next process seemed to follow. My read of that post was what you
and others have been advocating; it's more than what most teams need, it's
unenforceable, and tends to not reach the intended audience. I don't think the GitHub
flow being discussed goes back to that.
For me, I think the current process for patches is OK. There are
other areas
that I would concentrate on making simplification before changing the patch
process yet again.
For others, I think the current process is an itch we're dying to scratch.
Would love to hear about the other areas on your mind. I like thinking about this stuff.
-steve