Hello!
<quote name="Guillaume Paumier" date="2013-03-12" time="15:03:04 +0100">
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.
I've been wavering back and forth on this myself, honestly.
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.
So, a few things that are related to the above in no specific order:
1) Major changes/issues aren't always associated with just one merge. In this case a bug in BZ would be nice as it is more topical as opposed to tied to a specific merge.
2) Tracking the "most important changes" quality is something I think we need to do better, but I honestly haven't thought of The One Right Way (TM) yet. :) I experimented with keeping track of merges that I thought were interesting via 'starring' them in Gerrit, but the limit there is those stars are tied to my account, not a shared thing (ie: you can't add one to the list without having me do it).
Manually adding them to a wiki page is about as productive as something really unproductive. ;) (I tried that for a bit, too.)
Maybe clicking on a "file bug about this merge" and making that bug block a Release Notes tracking bug is useful? That also seems less efficient than a Gerrit "ReleaseNotes/Scaptrap" tag.
3) I have a personal preference for building light-weight tools first to see if that addresses the need then building more detailed/complex ones later as needed.
4) A Gerrit-based tagging plugin would need some engineering that might not be apparent at first blush, for example: who can set tags and remove them? Does that vary by tag? How could I, for example, keep track of all scaptrap-type things and be sure I don't miss something because someone mistakenly removed the scaptrap tag from a merge and I didn't notice/remember (ie: can I *trust* the tag, both what is there and what isn't, so I don't have to remember everything/double check every week?).
Just my $0.04 (penny per item).