[Python-Dev] Bug tracker: meaning of resolution keywords (original) (raw)

Brett Cannon brett at python.org
Sun Nov 11 00:56:31 CET 2007

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

More information about the Python-Dev mailing list