Gerrit/Tagging
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. In November 2014, Bugzilla was replaced by Phabricator; Gerrit Notification Bot adds Gerrit notifications to related Phabricator tasks. Gerrit might get replaced by Phabricator/Differential. |
This page serves as a specification for tagging in Gerrit
Old system
[edit]One feature of our old code review system that was a tagging system that made it quick and easy to assign a keyword to a revision at any time. There were a number of uses we had for the system, which are documented at Subversion/Code_review/tags
Examples of tags that we miss:
- scaptrap - this change requires special care at deploy time. It may be that it requires two components to be in sync that aren't generally deployed in sync, or it requires a configuration change, or something else.
- fixme - this change introduces a bug (weirdly, not in our old documentation - go figure). In Gerrit, this would be a -1 or -2 if the code hasn't been merged yet, but post-merge, there's no uniform way to attach that metadata.
- backcompat - backwards compatibility breakers.
One problem with tagging generally, though, is that it ended up being this weird parallel workflow to other systems. "fixme" was frequently used as a substitute for filing a bug report. "scaptrap" was a substitute for proper deployment notes, and "backcompat" was a solution for proper developer notes. That said, it was lightweight, which meant that it actually got used, as opposed to many "proper" solutions, which are frequently enough work that it's difficult to expect uniform followthrough.
Possible Gerrit Solutions
[edit]We're tracking solutions to this in bug 38239, currently assigned to Chad.
Addition to Gerrit core
[edit]This has been a frequently requested feature of the upstream Gerrit developers. However, they've been reluctant to implement such a feature until after some unscheduled major architectural work is completed, so we shouldn't hold our breath waiting for that.
Gerrit plugin
[edit]As of Gerrit 2.5, it's possible to create unofficial plugins to Gerrit via a stable, supported interface to the core. One solution is to use this mechanism to create our own tagging solution.
MediaWiki-based solution
[edit]Chad worked up a hacky version of tagging as a MediaWiki extension in early March 2013, which would have kept the tags in MediaWiki instead of Gerrit. That's only one half of what might be an acceptable solution, since the other half would need to be some Javascript in the Gerrit user interface to allow for insertion into the MediaWiki tag database.
Bugzilla-based solution
[edit]We are currently working on Bugzilla-Gerrit integration, which a form of tagging could be implemented for. The idea would be that, for any given revision, there would be a "file bug about this revision" link. Following that link would throw to the standard Bugzilla bug filing page, with as many fields prepopulated based on Gerrit context as could sensibly be filled (including, at the very minimum, a link back to the Gerrit rev, but probably also with the assignee set to the developer who introduced the issue, the component set based on the repo).
A Bugzilla-based solution would be an ideal replacement for "fixme", since fixmes are basically bugs anyway. It would work reasonably well for "scaptrap", since they generally imply something that needs to be done prior to deployment. It would be an awkward replacement for "backcompat" and others.
Still, the nice thing about this is that a Bugzilla-based solution is that it's general purpose enough that it may very well find use outside of Wikimedia-land. The BZ-Gerrit work is actually being done as part of a larger issue tracker plugin that the GerritForge folks have written to support Jira. Filing issues based on revisions is likely a common request for people integrating Gerrit with their issue tracking system.
Current plan
[edit]Current plan is to pursue the Bugzilla-based solution first. Discussion posted to the wikitech-l mailing list on 2013-03-09.[1]