Hi,
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
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.
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.
Thank you for this detailed e-mail. One thing I think I'm missing is why the bugzilla-based solution is better than the gerrit plugin one.
It seems to me that if the tagging functionality was developed as a gerrit plugin, it would have all the advantages of the bugzilla-based solution (good integration, etc.) without its drawbacks (awkwardness for non-bugs tags, e-mail addresses mismatches, dependency on bugzilla).
Admittedly, I'm not a primary user of gerrit, but I've been pondering the idea of using tags in order to surface noteworthy changes, so they can be easily listed and communicated about to our users. This would make it much easier to identify the "most important changes" on pages like https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf7 , and could also perhaps be used for release notes summaries.
A bugzilla-based tagging system seems too restrictive for this kind of use, but perhaps I'm just not seeing how it would work. It's difficult to predict the kinds of tags people will come up with in the future, and I feel it would be a pity to develop a tagging solution that restricts the type of tags you can use with it.
Just my $0.02 data point.