<div dir="ltr">In my own experience, not having iterative code reviews ends up being more trouble than it's worth.  But if others are in favor of reviewees squashing a commit per iteration during the actual pull, that's fine with me.  I personally prefer a fetch/rebase personal workflow so Gerrit works well for me when it works, but I understand with the issues we've been having with the server if there's a better or cheaper or more reliable alternative it's worth learning the new workflow.<div><br></div><div>Emily<br><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 21, 2017 at 1:56 AM Paul Menzel <<a href="mailto:pmenzel@molgen.mpg.de">pmenzel@molgen.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Dave, dear Andrew,<br>
<br>
<br>
On 12/20/17 23:27, Dave Cobbley wrote:<br>
> On 12/20/2017 12:31 PM, Andrew Geissler wrote:<br>
>> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley wrote:<br>
<br>
>>> I am curious to see peoples input on using github as a code<br>
>>> review mechanism over gerrit. I see github/openbmc is already<br>
>>> used quite well for sprint planning and issue tracking, I feel<br>
>>> like it would make a lot of sense to use it for doing code<br>
>>> reviews. As far as I understand it has a mechanism to reproduce a<br>
>>> similar paradigm to what we currently use today - as far as<br>
>>> Code-Review, Ok-To-Test, and Verified.<br>
>>><br>
>>> I can see github has made several improvements over the last few<br>
>>> years that make it much more use-able to teams like us:<br>
>>><br>
>>> - The ability to have approved maintainers for each specific<br>
>>> repository with<br>
>>> <a href="https://github.com/blog/2392-introducing-code-owners" rel="noreferrer" target="_blank">https://github.com/blog/2392-introducing-code-owners</a><br>
>>><br>
>>> - It has the ability to do a rebase-merge, keeping the git tree<br>
>>> nice and tidy.<br>
>>><br>
>>> - A strong API to tie in additional tools that we may need.<br>
>>><br>
>>><br>
>>> Additionally, it will reduce the point of failure from also<br>
>>> hosting gerrit.<br>
>>><br>
>>> What are peoples thoughts on using this?<br>
>> As the guy who ended up having to maintain the current gerrit<br>
>> server, I'm all for an alternative :)<br>
 ><br>
> First off - thanks for maintaining the current Gerrit server, I'm<br>
> sure it's as glamorous as it sounds :)<br>
 ><br>
>> But my problem is I really like gerrit.  github has def made some<br>
>> improvements to the review process though.  I see it has per-line<br>
>> comment ability now.<br>
 ><br>
> I have been using gerrit for quite a while and am quite accustomed to<br>
> it as well.<br>
 ><br>
>> I have a pull request out here for a non-gerrit openbmc repo if<br>
>> someone wants to look around -<br>
>> <a href="https://github.com/openbmc/openbmc-tools/pull/5" rel="noreferrer" target="_blank">https://github.com/openbmc/openbmc-tools/pull/5</a><br>
>><br>
>> One thing I really like is how gerrit allows you to iterate over a<br>
>> commit.  Someone makes some comments, you respond, upload a new<br>
>> patch set.  My understanding with github is you basically just keep<br>
>> adding on new commits in a pull request to address comments.  A<br>
>> feature I use all the time in gerrit is to look at the diff between<br>
>> a patch set I last reviewed and the latest one.  Also, I don't see<br>
>> an obvious mechanism in github to provide the different score<br>
>> levels (-2,-1,+1,+2)?  The gerrit dashboard is also really nice,<br>
>> providing me a nice easy way to see what's on my review list and<br>
>> what the current size and scores of those reviews are (for all<br>
>> repos in openbmc).<br>
 ><br>
> It appears that iterating over commits with github is as easy. When<br>
> someone checks in an additional commit to address some comments, you<br>
> can open their pull request, see the newest commit, and click on the<br>
> button which has the SHA on it, this will show you exactly what new<br>
> code has been checked in for that commit. When the code is ready to<br>
> be pulled into master, you can squash and merge to combine all<br>
> commits into one.<br>
<br>
It really depends on your development model and personal opinion, what<br>
is useful. Do you want a clean history and therefore allow rebasing or not.<br>
<br>
Then again, I do not understand why you should be forced to not force<br>
push to a branch so that the user interface can make your life easier.<br>
<br>
Personally, I do not understand how it is a good idea to squash all<br>
commits into one. You loose the ability to bisect small changes and the<br>
commit message probably also needs to be rewritten.<br>
<br>
Gerrit really excels GitHub in that regard. The only downside to my<br>
knowledge is, that merging is not supported in Gerrit. But a linear<br>
history is also fine.<br>
<br>
So as Gerrit is running, I personally would stay with Gerrit.<br>
<br>
> You're right about the review level, the only granularity I can see<br>
> is essentially a +0 (comment), and a +/-2 (Approve/request changes),<br>
> I would love to find a work around to this, or see if we could work<br>
> in a paradigm without +/- 1.<br>
><br>
> The gerrit dashboard is nice out of the box, but the github filter<br>
> gives you the same flexibility (and a bit more). I can set: is:open<br>
> is:pr review-requested:dcobbley to look at all reviews (awaiting<br>
> reviews from me), or is:open is:pr review:none (reviews that has no<br>
> review). I definitely think this issomething that people could easily<br>
> adjust to.<br>
 ><br>
>> We also base a lot of our current CI infrastructure off of gerrit<br>
>> events.  I think most of it can be switched over to using github,<br>
>> but it's not inconsequential.<br>
 ><br>
> I can definitely understand an upfront cost has already been given,<br>
> and switching to something else would require more work, but I don't<br>
> really want that to be a blocking issue if something else does offer<br>
> significant improvement (something I'm still trying to identify with<br>
> github vs gerrit).<br>
><br>
>> Our current gerrit VM costs on the order of $60 a year....so you<br>
>> get what you pay for.  I've been poking around IBM trying to see if<br>
>> we can get something a bit more production worthy.<br>
<br>
<br>
Kind regards,<br>
<br>
Paul<br>
<br>
</blockquote></div></div></div></div></div>