Here is my first draft of cleaning up some of the definitions
and adding a FAQ for the kernel tracker bugzilla. Comments
and flames welcome.
Hanna
-------
Status
OPEN - A new bug that no one is working on. Bugs in this state may
be accepted, and become ASSIGNED. The default owner (in charge of tracking
the bug) is the subsystem maintainer or the bugme-janitors mailing list.
ASSIGNED - This bug is assigned to someone who thinks they can fix it.
>From here bugs typically move to RESOLVED or REJECTED.
RESOLVED - A fix has been made, and it is awaiting more testing.
>From here bugs are usually either CLOSED or APPROVED.
APPROVED- The fix has been tested. But is not accepted into the mainline
kernel.
REJECTED-The bug has not been fixed. Possible reasons for rejections are
INVALID, DUPLICATE, UNREPRODUCIBLE, or INSUFFICIENT_DATA.
DEFERRED- The bug may or may not be fixed later.
CLOSED - The fix has been accepted into the mainline kernel.
Resolution
The resolution field indicates what happened to this bug.
No resolution yet: All bugs which are in one of the "open" states (meaning
the state has no associated resolution) have the resolution set to blank.
All other bugs will be marked with one of the following resolutions.
CODE_FIX - A fix(patch) for this bug has been generated.
PATCH_ALREADY_AVAILABLE - This problem has been fixed before and
there is a patch available for it.
INVALID - The problem described is not a bug.
WILL_NOT_FIX - The problem described is a bug which will never be
fixed.
WILL_FIX_LATER - The problem described is a bug which will not be
fixed in this version.
DUPLICATE - The problem is a duplicate of an existing bug. Marking
a bug duplicate requires the bug number of the duplicate and that number
will be placed in the bug description.
UNREPRODUCIBLE - All attempts at reproducing this bug were futile,
reading the code produces no clues as to why this behavior would occur. If
more information appears later, please re-assign the bug, for now, file it.
INSUFFICIENT_DATA - There is not enough information to resolve this bug.
--------------
Frequently Asked Questions
Q. How do I know if a bug is being worked on or not?
A. If it is not ASSIGNED to anyone then it is not being worked on.
Q. Why are the subsystem maintainers in kernel tracker sometimes
different than the person listed in the MAINTAINER file?
A. The subsystem maintainers in kernel tracker are volunteers to
help track bugs in an area they are interested in. Sometimes they
are the same person as on kernel.org sometimes they are not. There
are still some categories with no maintainers so more volunteers
are needed.
Q. What does a subsystem maintainer do?
A. He or She will track new bugs and assign them to people or
reject it for various reasons. They periodically check to
make sure things are getting worked on and review fixes to
make sure they are well written.
Q. If a bug has an owner does that mean they are workig on it?
A. No. If it is not in the ASSIGNED state then no one is working on it.
The owner defaults to the subsytem maintainer. However, anyone
who wants to submit a patch or add more info to a bug can do so.
If the bug is reassigned to someone then the owner field will
reflect that change.
Q. Can anyone add comments to a bug?
A. Yes but you will need to sign up for an account first.
Q. Who can change the status of a bug?
A. Only the subsystem maintainer. If you want to update
a bug put your comments in the comment or attachment fields.
Q. What is the difference between RESOLVED, APPROVED and CLOSED?
A. RESOLVED really should be renamed UNTESTED_FIX. That is
when a fix is available but needs more testing. APPROVED
is very poorly named and should be TESTED_FIX. This is the
last step before CLOSED. CLOSED means the fix has been
accepted into the mainline kernel.
Q. What would cause a bug to be REJECTED?
A. Probably the two most common reasons are the problem is a DUPLICATE
of another bug or the report is just badly written and there is not
enough info to do anything about it.
| -------
| Status
|
| OPEN - A new bug that no one is working on. Bugs in this state may
| be accepted, and become ASSIGNED. The default owner (in charge of tracking
| the bug) is the subsystem maintainer or the bugme-janitors mailing list.
Do new bugs go straight to OPEN with a default owner?
Where does someone sign up for this new mailing list?
--
~Randy
>| OPEN - A new bug that no one is working on. Bugs in this state may
>| be accepted, and become ASSIGNED. The default owner (in charge of tracking
>| the bug) is the subsystem maintainer or the bugme-janitors mailing list.
>
> Do new bugs go straight to OPEN with a default owner?
Yes. OPEN should really be called NEW. Will try to fix that as it
seems to be causing confusion. I don't particularly like the naming
of RESOLVED or ACCEPTED either, but we'll have to see how hard it
is to change these things.
> Where does someone sign up for this new mailing list?
Email me. But I'm going to keep it to a small tight group for now,
will see how it works out from there. At the moment bugs that have
not real owner just go to me or Khoa, so this is a step up, even if
it's not perfect.
M.