Draft for 'Bugzilla processes and procedures' mail to developers

John Poelstra poelstra at redhat.com
Thu Apr 2 04:22:44 UTC 2009


Adam Williamson said the following on 03/31/2009 02:50 PM Pacific Time:
> 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.

I think you are overstating a problem that I'm not sure exists.  We have 
defined the states here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Why not improve on what is there?

When this was discussed in January 2008 the idea was to add some 
structure, but not force people to follow it exactly.  We don't have 
that many states so it is hard to do really bizarre things.  For the 
most part I think the maintainers are okay with what we have. If the 
BugZappers exist to help the maintainers would this change really help them?

> 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.

What would be gained from "managing or monitoring" Fedora bugs in a 
different way than they are currently?  In other words, by forcing 
people to follow a more stringent process what benefit will it provide? 
     Is there a sufficient return on investment?

> 
> 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 states are well defined on the bugzilla pages, but the actual 
procedures and handling of RHEL bugs is internal to Red Hat (and not 
likely something Fedora would want to follow, but maybe some of the RHEL 
maintainers would disagree ;-)

> 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.

The fourth approach could be to use what we already have
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow and improve 
on it to fix what is thought to be broken.


> 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.
> 

How big of a problem is this today and how will fixing it make Fedora 
better?  In other words is the current ambiguity causing problems?  If 
it is not, why change it?  My impression is that preference varies among 
maintainers and usually depends on the specific situation.


> 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.
> 

What about turning this around and asking the maintiners what they see 
as the current problems with their interactions with bugzilla and how 
the bugzappers might help?  Just as an exmaple, what if most maintainers 
could care less about how multiple release bugs are filed, but really 
care about using the "priority field" then we could be more help to them 
by focusing on that.

I think it is great you want to tackle and clarify these things.  Having 
gone through a round myself with this process I guess I learned that 
some ambiguity wasn't as harmful as I first thought. :)

John




More information about the fedora-test-list mailing list