I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go?
- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.
- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.
Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(
- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.
- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.
I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)
We're going to build a bot that replies to pull requests to the Go core. It'll say "Sorry, we don't take pull requests, but here's how to use Gerrit [link]. Thanks!"
FYI if you have a "CONTRIBUTING" or "CONTRIBUTING.md" document at the project root, a neat little info bar "Please read the [contributing] guidelines before proceeding" will show up to anyone filing a bug or a PR.
I have to agree that not using pull requests is missing out on the best feature of github. It's the social, low-overhead way to contribute to a repo.
It seems like it must be possible to hook up a bot to github that watches for pull requests and submits them to gerrit... the Juju team has a bot that does that for our Reviewboard integration. It won't work for more complicated workflows that github doesn't support, like dependent branches or whatever, but it lowers the barrier of entry for initial contributors that just want to submit a simple fix. And the more advanced users can just submit directly to our Reviewboard instance if they want the more advanced features.
Also, the public fork on Github is actually a feature - it means others can easily see what you're working on. You need off-site storage for your personal work anyway, right? You're not going to keep it local on your laptop, so you'll need a branch somewhere regardless.
GitHub code review is terrible. I don't blame them for not using pull requests in the least. If not being able to pull is enough to stop people from contributing, how much is their contribution worth?
I think this is a great move. Also, very similar to the setup used for the OpenStack (http://openstack.org/) project. All reviews done in Gerrit, published to Github when merged. OpenStack also has the bot which closes GitHub pull requests and redirecting to Gerrit. More on their Gerrit/Github integration here: http://ci.openstack.org/gerrit.html
For those interested in doing the same for their own, private projects, there is http://forj.io (full disclaimer, I work on this project).
Finally, Gerrit now has an async / TTY based client which works offline (reviews on the go!) with Gertty - https://github.com/stackforge/gertty
- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.
- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.
Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(
- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.
- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.
I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)