dormant bugs and our perception
Matej Cepl
mcepl at redhat.com
Thu Jan 3 18:15:07 UTC 2008
On 2008-01-02, 16:07 GMT, Greg DeKoenigsberg wrote:
> Maybe. GNOME certainly tries this, as does Ubuntu. But
> Ubuntu's triage situation isn't much better than ours, from
> what I can tell.
>
> First, though, there needs to be someone who says "I Am The
> Bugmaster For Fedora." If the right leader emerges, the rest
> would probably follow quite naturally from that, I think.
I am not the one, I can only say that I am *a* bugmaster for the
Red Hat desktop team (employed by Red Hat). I can clearly see
that there is a huge need for bug triaging team on our bugzilla,
but let me add couple of notes here (actually is is getting
pretty long):
* I have no clue how to create the team -- it should be probably
done by somebody how would be more skilled in actual
team-building and stuff like that, than somebody able to plow
through bugzilla.
* There is a need to create a lot of documentation -- the stuff
which is available inside our Bugzilla is mostly obsolete
and/or misleading. Some stuff is available on gnome.org, but
their problems are slightly different than ours, about which
later.
We tried inside of the desktop team to build some Bug Triaging
policy. It is not finished yet (and it has desktop bias), so
just as an information about what we are thinking about it is
available at
http://mcepl.fedorapeople.org/docs/bug-triaging-guide.xhtml
Comments are more than welcome.
* Gnome.org and their bug triaging is often used as an example
how to do it.
Certainly, Luis did a lot of great work, but when we were
talking about it in summer (when he was interning in the Red
Hat legal department), we came to the conclusion that the
situation in our bugzilla is quite different.
The biggest concern of their bug triaging is to deal with the
flood of bug-buddy generated thousands of duplicates for
crashes in Gnome programs. On the one hand the flood is
intense, on the other hand, it is quite easily possible to
diagnose and massage these bugs with some scripts (see
http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates
and related pages).
Our bugs are all hand-written and very diverse in their
formats, so there is probably not much any script can do. We
have fewer duplicates than them, but each of them have to be
really opened by humans, analyzed, and decided upon. That means
that many strategies and ideas, they developed, is not directly
applicable to us.
* If I can judge by my almost-a-year-long experience with desktop
(and especially xorg), it seems to me that the one of the
biggest problems is lack of the bug retention policy. If our
bugzilla is supposed to be a tool for developers, we must get
keep cleaning our BZ for all bugs which will most likely be
never dealt with and keep all remaining active bugs fresh all
the time. See the above draft of the bug triaging policy for
some ideas I have on this.
* Other issue (which doesn't happen in Gnome bugzilla at all) is
upstreaming -- what bugs should go upstream, and how to deal
with them in our BZ. Again, although some improvement can be
made by developing of some tools for doing the work, there is
plenty of work which could be done by bug triagers -- if we
just don't want to dump our trash over the fence to
a neighbor's garden, we have to search upstream bugzillas (or
other bug databases) for the upstream bugs, and to maintain the
link between the state of them and our bug.
Concerning the dealing with them in our BZ -- when we close
them as UPSTREAM, it is kind of hypocritical situation. We just
don't want to see them anymore. However, IMHO the proper
solution would be to deal with the upstream bugzilla as a kind
of developer -- the bug should be (kind of) ASSIGNED to it, and
when the upstream generates a patch (or new release containing
the fix) we should apply it and QA it (at least by asking
reporter to test the new package)
* And there is no magical solution -- “drastic measures” will
IMHO not provide long term solution to our problems, and will
(if they will make any change at all) just hide them and delay
the proper solution.
That's probably all what goes through my head just now.
Any reactions?
Matej
More information about the advisory-board
mailing list