Gerrit alternatives

Gerrit alternatives

[Dave Cobbley]

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

-Dave Cobbley

Re: Gerrit alternatives

[Andrew Geissler]

On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley
<david.j.cobbley@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
> 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 :)

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

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.

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.

Andrew

>
> -Dave Cobbley
>

Re: Gerrit alternatives

[Dave Cobbley]

On 12/20/2017 12:31 PM, Andrew Geissler wrote:
> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley
> <david.j.cobbley@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
>> 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.

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.
>
> Andrew
>
>> -Dave Cobbley
>>
Thanks for the feedback!
-Dave

Re: Gerrit alternatives

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 5115 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]

Re: Gerrit alternatives

[Emily Shaffer]

[-- Attachment #1: Type: text/plain, Size: 5758 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7178 bytes --]

Re: Gerrit alternatives

[Stewart Smith]

Andrew Geissler <geissonator@gmail.com> writes:
> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley
> <david.j.cobbley@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
>> 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 :)
>
> 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 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).

Basically all those features is why I like review via email and
patchwork. You can review/comment as much as you like, anywhere, easily,
even offline. As a maintiner, patchwork is invaluable, and passes the
"somebody else maintains it" test, while still actually being open.

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

Some of the CI integration in patchwork needs a bit of work though. We need to bribe
the grads with something in order to get snowpatch fixed up :)

-- 
Stewart Smith
OPAL Architect, IBM.