david.j.cobbley at linux.intel.com
Thu Dec 21 09:27:53 AEDT 2017
On 12/20/2017 12:31 PM, Andrew Geissler wrote:
> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley
> <david.j.cobbley at linux.intel.com> wrote:
>> Hey all,
>> I am curious to see peoples input on using github as a code review mechanism
>> over gerrit. I see github/openbmc is already used quite well for sprint
>> planning and issue tracking, I feel like it would make a lot of sense to use
>> it for doing code reviews. As far as I understand it has a mechanism to
>> reproduce a similar paradigm to what we currently use today - as far as
>> Code-Review, Ok-To-Test, and Verified.
>> I can see github has made several improvements over the last few years that
>> make it much more use-able to teams like us:
>> - The ability to have approved maintainers for each specific repository with
>> - It has the ability to do a rebase-merge, keeping the git tree nice and
>> - A strong API to tie in additional tools that we may need.
>> Additionally, it will reduce the point of failure from also hosting gerrit.
>> What are peoples thoughts on using this?
> As the guy who ended up having to maintain the current gerrit server,
> I'm all for an alternative :)
First off - thanks for maintaining the current Gerrit server, I'm sure
it's as glamorous as it sounds :)
> But my problem is I really like gerrit. github has def made some
> improvements to the review process though. I see it has per-line
> comment ability now.
I have been using gerrit for quite a while and am quite accustomed to it
> I have a pull request out here for a non-gerrit openbmc repo if
> someone wants to look around -
> One thing I really like is how gerrit allows you to iterate over a
> commit. Someone makes some comments, you respond, upload a new patch
> set. My understanding with github is you basically just keep adding
> on new commits in a pull request to address comments. A feature I use
> all the time in gerrit is to look at the diff between a patch set I
> last reviewed and the latest one. Also, I don't see an obvious
> mechanism in github to provide the different score levels
> (-2,-1,+1,+2)? The gerrit dashboard is also really nice, providing me
> a nice easy way to see what's on my review list and what the current
> size and scores of those reviews are (for all repos in openbmc).
It appears that iterating over commits with github is as easy. When
someone checks in an additional commit to address some comments, you can
open their pull request, see the newest commit, and click on the button
which has the SHA on it, this will show you exactly what new code has
been checked in for that commit. When the code is ready to be pulled
into master, you can squash and merge to combine all commits into one.
You're right about the review level, the only granularity I can see is
essentially a +0 (comment), and a +/-2 (Approve/request changes), I
would love to find a work around to this, or see if we could work in a
paradigm without +/- 1.
The gerrit dashboard is nice out of the box, but the github filter gives
you the same flexibility (and a bit more). I can set: is:open is:pr
review-requested:dcobbley to look at all reviews (awaiting reviews from
me), or is:open is:pr review:none (reviews that has no review). I
definitely think this issomething that people could easily adjust to.
> We also base a lot of our current CI infrastructure off of gerrit
> events. I think most of it can be switched over to using github, but
> it's not inconsequential.
I can definitely understand an upfront cost has already been given, and
switching to something else would require more work, but I don't really
want that to be a blocking issue if something else does offer
significant improvement (something I'm still trying to identify with
github vs gerrit).
> Our current gerrit VM costs on the order of $60 a year....so you get
> what you pay for. I've been poking around IBM trying to see if we can
> get something a bit more production worthy.
>> -Dave Cobbley
Thanks for the feedback!
More information about the openbmc