Gerrit alternatives

[Emily Shaffer]

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.

Emily

On Thu, Dec 21, 2017 at 1:56 AM Paul Menzel <pmenzel at molgen.mpg.de> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171221/2b53666b/attachment-0001.html>