Draft for 'Bugzilla processes and procedures' mail to developers

[Christopher Beland]

On Tue, 2009-03-31 at 14:50 -0700, Adam Williamson wrote:
> 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

There is also something of a hybrid approach we were discussing: keep
one bug, until a fix is released.  If a fix does not come out for a
given release and someone wants to advocate for a backport, they can
file a separate bug at that time.


> The first proposal is that we simply use the same procedure (and
> hence the same statuses and resolutions) for Fedora....
> 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.

Well, looking at this page:

https://bugzilla.redhat.com/page.cgi?id=fields.html

it seems that there are actually several states that RHEL doesn't use
that Fedora does.

Were there any other documents that we found that describe the RHEL
process in detail?  It might be nice to send out links to developers
to say, "And for proposal #1, what Fedora would adopt would be based
on *this*, after further discussion."

The only automatic transitions are:
 MODIFIED -> ON_QA
 ON_QA -> RELEASE_PENDING
 RELEASE_PENDING -> CLOSED/ERRATA

I think those are automated for supported Fedora releases, but not for
Rawhide?  Perhaps there is some room to improve automation so that
Rawhide changes that are supposed to fix a certain bug automatically
mark bugs CLOSED/RAWHIDE when the build gets released?  In the
meantime, it doesn't seem like a big downside to simply document that
developers (or whoever) needs to do that manually.


Two things that the above URL says aren't used in RHEL are
"WORKSFORME" and "UPSTREAM".  I guess I would have two questions to
answer to clarify this page for Fedora use.

1.) Who decides when to set a bug CLOSED/UPSTREAM, and what are the
criteria for doing so?  And specifically, should triagers be expected
to try to make this determination?

2.) Should WORKSFORME be banned?  It seems that for RHEL, the correct
answer is never "I tried it and it worked so there's probably not a
bug".  The alternative is to push reports back as NEEDINFO until they
are resolved as NOTABUG (if it turns out to be user error) or
CLOSED/RAWHIDE or the bug is isolated with the reporter's help.
Usually these cases are either 1.) there is some local state (user
configuration, hardware, etc.) that is triggering the bug or 2.)
different people are testing different versions.  Either way, further
testing can resolve the question.


"RAWHIDE" is also not used in RHEL.  Conversely, the only state I see
(correct me if I'm wrong) that's not used in Fedora is VERIFIED.


The (entirely sensible) way you laid out the question was: "We can
either 1.)  use exactly the same procedure for RHEL and Fedora 2.) use
a simplified version of RHEL for Fedora, or 3.) try to come up with
something from scratch for Fedora."

Based on the opinions expressed so far, I assume that there will be
general agreement that making the two reasonably similar would be
convenient. So the way I am thinking about the answer is: "What should
the differences between Fedora and RHEL bug flow procedures be, if
any?" The answer becomes clearer in my mind after seeing the actual
concrete differences in current practices laid out.  (Or at least the
key decisions that will have to be made.)

I don't know whether it's a good idea to get into details in the
initial message to fedora-devel-list, but hopefully the discussion
will output some concrete answers.

-B.