GNOME Bugzilla – Bug 706155
Have a dedicated Code Review tool in GNOME infrastructure (e.g. Gerrit)
Last modified: 2017-10-14 18:36:20 UTC
I'd like to open a discussion about Gerrit as a patch review option in addition to Bugzilla. Gerrit is very, very good at patch series. Bugzilla is a bug tracker, and it's convenient to attach one or two patches in relation to a bug.
We'd probably want to have some cross-linking between Gerrit, Bugzilla, and the actual git repos, so that if we push a branch that went through Bugzilla, the bug is auto-updated.
At the moment a number of developers push wip/topicname branches, and our git is configured to allow fast-forward of those. Then developers can review by looking at cgit or fetching, but Gerrit provides numerous advantages over wip/topic model:
1) It has tools to show you the interdiff between series - this is *extremely* useful for reviewers
2) It records a permanent record of review; the wip/topic model leaves it up to the developers to choose a communication mechanism such as IRC or email.
(In reply to comment #0)
> At the moment a number of developers push wip/topicname branches, and our git
> is configured to allow fast-forward of those.
I assume you mean "non fast-forward updates" here.
Since I'm actually unfamiliar in this territory, how does Review Board hold up against Gerrit? chipx86 might be able to set us up with a trial version of Review Board on RBCommons as well.
That discussion should probably happen on d-d-l. :)
(In reply to comment #0)
> if we push a branch that went through Bugzilla, the bug is auto-updated.
If we are going to consider code review tools, we should also seriously consider phabricator, which I prefer over gerrit. It is lighter weight server side and is quite a bit nicer (visually). The workflow is vaguely the same for the two.
At work we use Gerrit for both code/review and repository management (ACL / repo creation)
> 20k review
> 120 repos
~ 100 users
resource usage is pretty low (apart for disk space) and the level of maintenance is almost 0.
FWIW big project like Android / Wikimedia / Openstack use Gerrit.
Let me know if you need more details
LibreOffice uses gerrit, and (after some initial default conservatism ;-) we're extremely happy with it:
git commit -a
git push origin HEAD:refs/for/libreoffice-4-1
git reset --hard HEAD~1
is rather a beautiful frontend for submitting to a review flow ;-) [ just in case that helps ].
RBCommons is probably not the right solution, because it's locked down for private use inside companies, but I'd recommend trying out the open source version of Review Board in addition to gerrit. A lot of our users have used both, and prefer the user experience of Review Board significantly.
I just suggested it since it's more of a "GNOME" project, and we might be able to do a trial fairly quickly and efficiently.
I really don't care what eventually is used. Either Review Board or Gerrit would be great, and I'm sorry if I made it never happen because I started the bikeshedding. Pick one and try it out.
I fully agree with Jasper, let's not turn this discussion into a stale one and move forward. Jasper, can you get us a review board testing istance as per comment #1 so people can start trying things out?
I could get an RBCommons account, but I'd be paying for it out of my own pocket, and I'm not sure whether we can import/export data from it if we deploy a real RB instance ourselves. I figured that chipx86 might be able to lend us a helping hand if he's still around, but if we simply want to set up Gerrit and call it a day, fine by me.
ReviewBoard can be quickly setup on OpenShift, for instance, see https://www.openshift.com/blogs/how-to-setup-and-run-a-review-board-instance-on-openshift.
Another nice feature in RB is that a review comment can be filed as an internal issue, this significantly helps to keep a todo list for submitted patch
Gerrit is a very nice tool for patch review. The verifier part would also allow us to run certain (e.g. style) tests automatically before a human reviewer would look at it. Later this could even trigger a build or similar.
Transcript of brief discussion today. Still TODO is investigate bugzilla.mozilla.org's use of splinter and their workflow.
<walters> owen: any opinions on https://bugzilla.gnome.org/show_bug.cgi?id=706155 ?
<Services> Bug 706155: normal, Normal, ---, sysadmin-maint, UNCONFIRMED, gerrit
<owen> walters: No
<walters> no as in...we should not use gerrit, no as in no opinion?
<owen> walters: Basically, I don't want to stop something if there's momentum to use it, and I'm not doing much review at the moment anyways, so I'm probably not the right person have opinions. I chose to push us towards Splinter rather than gerrit, etc, because I thought integrating multiple systems would lead to a confused workflow, but I'm sure gerrit has significant advantages too
<walters> it's worth considering improving splinter for sure; the main issue is the fact that bugzilla and git are disconnected systems with separate authentication mechanisms
<av> walters: which role is bugzilla going to play in the hypothetic gerrit's move?
<walters> i guess what i find myself suffering from the most is all of the round trips and manual steps; like when a patch is marked a-c-n, i then have to push it manually
<walters> av: ah...i think bugzilla would still track bugs, and would still be used for some single patches. But it's just really not great at continually evolving patch series
<owen> walters: I doubt splinter improvemnts are going to happen, we don't have a supply of the right sort of development contribution for that
<walters> development resources are one thing, but some improvements would need fundamental architecture rearrangement
<walters> like for autolanding, we really want to link up bugzilla accounts and LDAP
<walters> and ensure that the patches pushed to bugzilla for review are submitted via ssh so we've authenticated
<walters> that is where gerrit is different in that it sits directly on top of git
<owen> that kind of stuff requires development resources too
<owen> walters: doesn't sitting directly on top of git lock out new contributors unless we signiicantly revamp our acounts system?
<walters> yes, it does; although of course with git they can set up their own repo somewhere and file a bug for manual review. If they're going to be continual contributors then it shouldn't be a problem to get them an account
<av> walters: does keeping bugzilla and gerrit up together make any sense? I'm not strictly a developer so I don't know how the workflow would change if we introduce another reviewing system and keep bugzilla + splinter up
<av> walters: the only point in keeping BZ up would be to help new contributors sending patches without the need of an ssh account
<walters> av: i think it makes sense to have bugzilla and gerrit together, and the fact that splinter exists in bugzilla means it shouldn't cost us very much to keep it up there
<walters> i guess the only cost is bugzilla rebases but i don't know how much their internals change
<av> owen: was splinter migrated to the new BZ 4.X format btw?
<owen> av: Splinter (somewhat rewritten) is used on bugzilla.mozilla.org
<walters> oh interesting
<walters> i'm curious about their workflow, like whether they have any autolanding, or developers just push from their own machines
FYI here's also some Mozilla experience with bugzilla, splinter and review board - https://wiki.mozilla.org/Auto-tools/Projects/BugzillaReviewImprovement
(In reply to comment #12)
> <av> walters: which role is bugzilla going to play in the hypothetic gerrit's
We use Bugzilla and Gerrit in Wikimedia and there are quite some users who refuse to create a Gerrit account and still attach patches in Bugzilla. Which defacto means that they will rot if nobody copies them to Gerrit.
Hence "burden to create yet another account" and workflow to get these patches from Bugzilla into Gerrit is stuff to think about. Would love to hear from LibreOffice folks if they have the same experience (or how they fixed it).
The tizen project uses gerrit. It's okay, although I find it's permission systems to be somewhat opaque and hard to understand at times.
Phabricator looks kind of cool as well. +1 for that and review board.
We use Bugzilla and Gerrit in Eclipse. It makes sense to have both of course, one is for tracking bugs/features and the other is for reviewing code or other changes.
As for accounts, you only have to create an "eclipse.org" account once and can use it to access Bugzilla, Gerrit and other systems. I don't know about the details of the implementation of that, maybe it uses LDAP. But in any case, it's a problem that can be solved (and that other review systems also have, except for ones integrated into Bugzilla).
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE.
The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue.
More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker.
Thanks for your patience,
the GNOME Infrastructure Team
So that's now https://rt.gnome.org/Ticket/Display.html?id=14040 that I cannot access and basically no other stakeholders either, except for sysadmins.
I guess that effectively killed any community conversation about introducing Gerrit.
Me and Andre had an interesting discussion about our RT instance and how well it suits sysadmin's needs but not contributors'. If you have worked with RT long enough you surely know how great managing tickets with it is and that's what the Sysadmin Team was actually looking for when we made the switch: an easy to use and powerful ticketing system to manage all sysadmin-related issues each of them divided by topic or area of operation on single queues. Tickets were then accessible by requestors (or CCed people) and sysadmins.
1. easy to use and intuitive web UI, working with it is a charm
2. tickets divided by topic or area of intervention
3. hooks with PagerDuty for Emergency queues
4. tickets transactions being sent to the gnome-infrastructure mailing list (with sysadmins being able to moderate or not a certain transaction in case it contained personal information on its body)
1. no easy way to view tickets that belong to other users
2. visibility of transactions is possible but through the search bar at https://mail.gnome.org/archives/gnome-infrastructure
2a. no references of a certain ticket (like in the case of Gerrit) means no further replies? hard to tell
The proposed solution:
1. Upgrade BZ
2. Introduce a sysadmin product again with a reviewed selection of components
3. Keep RT for queues that are going to receive personal information such as IPs, surnames, addresses (accounts queue for example)
4. Keep RT for emergency requests, we still want the Pagerduty hooks in place
5. BZ will be also handy to manage GNOME Infrastructure Apprentice Group tasks and keep track of them publicly
6. Review the website product components
Let's hope the proposed solution will actually bring back some activity on sysadmin tickets and most of all some participation from our beloved community.
Re-opening this bug as it's still valid.
FWIW I'm working on something to enhance code review you might be interested in, here a paste of an email to the bugmasters: http://pastebin.com/raw/S1jwmw6F
It'll be doable independently of what tool you use for review I think, I'm currently building an abstraction exactly for that. Also somewhere on the roadmap is a feature that tracks comments in certain lines over revisions of commits and reminds people of fixing them if the associated line isn't changed (this was mentioned here somewhere in the first comments.)
Is this something we still want to do? Is considering GitLab an option?
We now have Splinter here on Bugzilla, and are moving to GitLab, so this seems definitely obsolete.