Draft for 'Bugzilla processes and procedures' mail to developers

[Adam Williamson]

Hi, guys. As discussed in this morning's meeting, I'm sending a draft of
a mail I propose to send to fedora-devel-list to ask for the opinions of
the developer group on what we should do about Bugzilla policies and
procedures. Does it look OK to everyone? Any suggestions to refine or
improve it? Thanks!

---------------------------------

Hi, -devel-list folks!

We in the Bugzappers team (part of the QA group) are working to revise
our Wiki space, and as part of that, various questions have arisen with
regards to Bugzilla procedures. A lot of the same issues have come up on
this list in the recent past.

In general, it seems like Fedora doesn't really have a properly defined
procedure for exactly how a bug should flow. Every maintainer, reporter
and triager has a slightly different idea of what each status or
resolution or keyword means, and when and by whom they should be
applied.

This is obviously confusing and problematic for any attempt to manage or
monitor Fedora bugs in a systematic way. We should have a consistent
procedure which works for reporters and developers and can be monitored
and managed by the Bugzappers group.

So, to arms!

General bug flow
----------------

This section covers things like "what do all the statuses mean" and
"what do all the resolutions mean" and "who changes what from what to
what, and when".

There is a very well-defined procedure for handling bugs in RHEL. The
first proposal is that we simply use the same procedure (and hence the
same statuses and resolutions) for Fedora. This has the advantage of
giving us a well-defined and tested process which some maintainers will
already be familiar with. The disadvantage of this is that the RHEL
process is probably in some ways over-engineered for Fedora: it uses
several stages managed by different teams which don't really exist so
far as Fedora is concerned, and relies on certain automatic steps which
aren't, AFAIK, actually automated for Fedora.

The second proposal would be to adopt some kind of simplified version of
the RHEL process, using a subset of the same statuses and resolutions,
usually to mean the same thing RHEL uses, with a less complex procedure
for getting all the way from file to fix.

The third proposal would be just to come up with a process for Fedora
from scratch, based probably on some kind of consensus around the
current practices used by various groups.

Specific issues
---------------

So, that's the overview. To get down to some specific issues, here's the
two big ones that have come up:

1) How to handle bugs that occur in multiple releases

There's no obvious One Good Fix for this one, because Bugzilla just
isn't designed to handle it. The two options most heavily discussed
within Bugzappers so far have been:

i) have reporters file separate bugs for each affected release that
someone cares about
ii) track all affected releases via one bug, using comments or keywords

Myself and Vincent Danen tried to come up with a flag-based system for
Mandriva to solve this problem once, but we couldn't really come up with
something that would work better than issue ii) above.

Personally I happen to prefer option i), but either can be made to work.
The most important thing is to pick one option or the other and apply it
consistently. This would mostly be the Bugzappers team's job, but
maintainers obviously have to know the policy chosen and work with it,
and Bugzappers don't want to try and just impose one choice or the
other, we want to know what would be most comfortable for maintainers.

2) What do we do with the Severity and Priority fields

At present these are pretty much roundly ignored by everyone (mostly on
the basis that they're initially set by reporters, who don't follow any
particular procedure, and so they don't convey any useful information).
I personally favour a policy whereby the Bugzappers group would set
these as a part of triage (their choices could be overridden later by
the package maintainer or RelEng). Severity should indicate the
importance of the issue *in the context of the package*, while Priority
indicates the importance of the issue *in the context of the
distribution as a whole*. So a crasher bug in a package only two people
in the world ever use may be High severity but Low priority, while say a
missing icon for Firefox might be Low severity but High priority. In my
experience, if these fields are consistently set by triagers according
to an agreed policy, they do convey valuable information to maintainers
and maintainers (and RelEng) find them useful.

Please, any feedback from active maintainers is most valuable - what I'm
trying to do here is find out what those who use Bugzilla at the sharp
end most need it to work like, to make their work most efficient. We in
Bugzappers see our mission as helping reporters to file useful reports
and maintainers to fix bugs as quickly and easily as possible, so we
want to set our policy based on what will work best for reporters and
maintainers.

Thanks!

----------------------------


-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net