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(a)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 |