Good point. Comments below...
On Tue, Mar 12, 2013 at 7:03 AM, Guillaume Paumier
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier
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.
The Bugzilla-based solution has some of the advantages of the
MediaWiki-based solution. We may be able to implement it more quickly
than something native to Gerrit because we're already working on
Bugzilla integration, and we get features like queries for free, as
well as the minor convenience of not having to have a new database
table or two to manage. It may be useful for Chad and/or Christian to
weigh in on this point.
* We're already managing Bugzilla (Andre is full-time on it), so
managing "tags" is straightforward.
* We get all sorts of extra management functions, such as assignee
with BZ, whereas "fixme"s, for example, only have an implicit,
unchangeable assignee (the committer)
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
True. They may not be mutually exclusive, but a question of ordering
and priority. A BZ-based solution can potentially be our short-term
solution, while we still continue to prod upstream on a better
long-term solution. We may also still decide that both features are
useful enough to implement them both ourselves.
The nice thing about a BZ-based solution is that we will probably
still want to keep using it for some things after there's a proper
upstream solution. Perhaps we'll also grow attached to a homegrown
tagging solution for Gerrit, but it seems less likely we'll want to
keep it unless the Gerrit devs never get around to implementing
tagging in core.
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
, 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.
I think we probably just need to be accommodating for more uses of
Bugzilla than narrowly using it for bugs only. I think these would be
perfectly fine to track in Bugzilla.
If the problem is with the rigidity of keywords, one thing I should
note is that, in addition to tagging, there's also the "whiteboard" in
Bugzilla, which I believe you can use for free form stuff to query. I
believe Andre only enabled that in recent months, so it may be that it
wasn't available the last time you went looking, and is a feature we
don't yet use for much (or anything?)
Part of why I sent my proposal to the list is because I'm not too
wedded to a Bugzilla-based solution. The main things I wanted to
1. Should we tackle Gerrit->Bugzilla bug filing as a higher priority
than a Gerrit tagging system? (My original assumption is "yes", but
this is the point I'm most malleable on)
2. Is a MediaWiki-based solution with some JS integration to Gerrit
acceptable alternative to building a Gerrit-only plugin? (My
assumption is "no")