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 <ro...@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). -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
