Hi folks,
Short version: This mail is fishing for feedback on proposed work on
Gerrit-Bugzilla integration to replace code review tags.
Long version:
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 here:
http://www.mediawiki.org/wiki/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.
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.
With that in mind, we have bug 38239, assigned to Chad:
https://bugzilla.wikimedia.org/38239
Chad worked up a hacky version of tagging as a MediaWiki extension
earlier this week, 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. I discouraged Chad from continuing on this because it
seemed to me that it would have been a little *too* hacky. I
preferred that if we were going to have our own hacky solution, it
should at least be implemented as a Gerrit plugin, so that it would at
least stand a chance of becoming a well-integrated solution.
The 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.
The solution that Chad and I discussed is an addition to the
Bugzilla-Gerrit plugin that Christian is already working on. 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.
Is a Bugzilla-based solution worthwhile enough for our purposes for a
modest (but probably not insignificant) investment in this area, or
should we prioritize other Gerrit work higher (say, for example, a
native Gerrit tagging plugin)? Assuming we move forward with
development, anything we need to consider?
I've put the bulk of this email on
mediawiki.org here:
http://www.mediawiki.org/wiki/Git/Tagging
We should evolve that page into a spec for the work that Chad and
Christian will be doing.
Rob