Gerrit alternatives
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
Quoted 18 lines · 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.
Quoted 6 lines
- 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
Quoted 3 lines
-Dave Cobbley
Quoted 20 lines · Andrew Geissler
Quoted 18 lines · 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.
Quoted 8 lines
Quoted 6 lines
- 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 :)
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 10 lines
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.
Quoted 3 lines
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).
Quoted 9 lines
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
Quoted 2 lines
-Dave Cobbley
Thanks for the feedback!
-Dave
Dear Dave, dear Andrew,
Quoted 49 lines · Dave Cobbley
Quoted 20 lines · Andrew Geissler
Quoted 18 lines · Dave Cobbley
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.
Quoted 6 lines
Quoted 4 lines
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 :)
Quoted 1 line
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.
Quoted 12 lines
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).
Quoted 6 lines
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.
Quoted 12 lines
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.
Quoted 10 lines
Quoted 2 lines
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).Quoted 3 lines
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
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
Quoted 117 lines · Paul Menzel
Dear Dave, dear Andrew,
Quoted 57 lines · Dave Cobbley
Quoted 23 lines · Andrew Geissler
Quoted 21 lines · Dave Cobbley
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.
Quoted 6 lines
Quoted 4 lines
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 :)
Quoted 3 lines
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.
Quoted 4 lines
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/5Quoted 11 lines
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).
Quoted 7 lines
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.
Quoted 16 lines
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.
Quoted 3 lines
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.
Quoted 9 lines
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).
Quoted 3 lines
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
Quoted 38 lines · Andrew Geissler
Quoted 18 lines · 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.
Quoted 6 lines
- 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
Quoted 10 lines
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.
Quoted 3 lines
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 :)
Signature · 2 lines
Stewart Smith OPAL Architect, IBM.