Julien Danjou, the project technical lead for the OpenStack Ceilometer project, had some choice words to say about github pull requests, which resonates very strongly with me:
The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You’re a click away to send your contribution to any software. But the problem is that any worthy contribution isn’t an effort of a single click.
Doing any proper and useful contribution to a software is never done right the first time. There’s a dance you will have to play. A slowly rhythmed back and forth between you and the software maintainer or team. You’ll have to dance it until your contribution is correct and can be merged.
But as a software maintainer, not everybody is going to follow you on this choregraphy, and you’ll end up with pull-request you’ll never get finished unless you wrap things up yourself. So the gain in pull-requests here, isn’t really bigger than a good bug report in most cases.
This is where the social argument of Github isn’t anymore. As soon as you’re talking about projects bigger than a color theme for your favorite text editor, this feature is overrated.
After working on OpenStack for the last year, I’m completely spoiled by our workflow and how it enables developer productivity. Recently I went back to just using git without gerrit to try to work on a 4 person side project, and it literally felt like developing in a thick sea of tar.
A system like Gerrit, and pre-merge interactive reviews, lets you build project culture quickly (it’s possible to do it other ways, but I’ve seen gerrit really facilitate it). The onus is on the contributors to get it right before it’s merged, and they get the feedback to get a patch done the right way. Coherent project culture is one of the biggest factors in attaining project velocity, as then everyone is working towards the same goals, with the same standards.
It's always more complicated 
There is a new Gerrit plugin project now that is focused on bridging the two worlds, allowing the management of GitHub pull requests through a more ordered and production Code Review with Gerrit, creating a Change with associated review from GitHub requests.
The “pull requestor” can still receive its notifications on GitHub whilst the entire Code Review happens on Gerrit. Hopefully this will bring the best of both worlds 🙂
For more info:
https://gerrit-review.googlesource.com/#/admin/projects/plugins/github
Luca.
LikeLike
That article didn’t resonate quite as strongly with me, and I also wrote a response: http://blog.adamspiers.org/2013/05/12/in-partial-defense-of-githubs-review-system/
LikeLike
While I agree that sometimes Github pull requests can be a bit messy (if it’s author doesn’t have a proper culture towards managing change sets), the approach that Gerrit uses seem too limiting.
The thing is that some patches can be rather large and it is hard to review all changes altogether. In that case splitting them into commits with meaningful names could help reviewer to 1) better understand what’s going on; 2) review changes in several takes, reviewing one complete change (commit) at once.
LikeLike
Remember, gerrit is just git as well. So when you push an edge case (like a deep patch queue that you want in chunks, but only makes sense as the whole), you can just git review -d to pull local and experiment locally. I agree that patch series visualization could be much better.
LikeLike