[Python-Dev] Bug tracker: meaning of resolution keywords

[Brett Cannon]

On Nov 9, 2007 9:05 AM, Christian Heimes <lists at cheimes.de> wrote:
> Hello!
>
> Guido has granted me committer privileges to svn.python.org and
> bugs.python.org about a week ago. So I'm new and new people tend to make
> mistakes until they've learned the specific rules of a project.
>
> Today I've learned that the resolution keyword "accepted" doesn't mean
> the bug report is accepted. It only means a patch for the bug is
> accepted. In the past I've used "accepted" in the meaning of "bug is
> confirmed" in my own projects. In my ignorance I've used it in the same
> way to mark bugs as confirmed when I was able to reproduce the bug myself.
>
> The tracker doc at http://wiki.python.org/moin/TrackerDocs/ doesn't have
> a formal definition of the various keywords. I like to add a definition
> to the wiki to prevent others from making the same mistake. But first I
> like to discuss my view of the keywords
>
> Resolutions
> ***********
>
> accepted - patch accepted
> confirmed (*) - the problem is confirmed
> duplicate - the bug is a duplicated of another bug
> fixed - the bug is fixed / patch is applied
> invalid - catch all for invalid reports
> later - the problem is going to be addressed later in the release cycle
> out of date - the bug was already fixed in svn
> postponed - the problem is going to be fixed in the next minor version
> rejected - the patch or feature request is rejected
> remind - remind me to finish the task (docs, unit tests)
> wont fix - it's not a bug, it's a feature
> works for me - unable to reproduce the problem

It doesn't really work for you if you can't reproduce it.  =)

An important thing to remember is all of the states are there because
they are hold-overs for SourceForge's bug tracker, not from choice.
SOMEDAY, damn it, I am going to have the time to work on redesigning
our workflow is how WE want it to be and makes sense for us.  Then we
can have a doc like Django has
(http://www.djangoproject.com/documentation/contributing/#ticket-triage)
which would spell all of this out.

But as Christian knows first hand from me not getting to any of my
bugs quickly as of late, I don't have the time right now.  =(  But I
have stopped adding to my list of stuff to do for Python (it is
already long enough as it is) so that I will eventually get to this in
2008.

-Brett