Gerrit alternatives

[Paul Menzel]

Dear Dave, dear Andrew,


On 12/20/17 23:27, Dave Cobbley wrote:
> On 12/20/2017 12:31 PM, Andrew Geissler wrote:
>> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley wrote:

>>> 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 
>>> https://github.com/blog/2392-introducing-code-owners
>>> 
>>> - It has the ability to do a rebase-merge, keeping the git tree
>>> nice and tidy.
>>> 
>>> - 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 as well.
 >
>> I have a pull request out here for a non-gerrit openbmc repo if 
>> someone wants to look around - 
>> https://github.com/openbmc/openbmc-tools/pull/5
>> 
>> 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.

It really depends on your development model and personal opinion, what 
is useful. Do you want a clean history and therefore allow rebasing or not.

Then again, I do not understand why you should be forced to not force 
push to a branch so that the user interface can make your life easier.

Personally, I do not understand how it is a good idea to squash all 
commits into one. You loose the ability to bisect small changes and the 
commit message probably also needs to be rewritten.

Gerrit really excels GitHub in that regard. The only downside to my 
knowledge is, that merging is not supported in Gerrit. But a linear 
history is also fine.

So as Gerrit is running, I personally would stay with Gerrit.

> 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.


Kind regards,

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171221/787d8122/attachment.bin>