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