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

Facundo Batista facundobatista at gmail.com
Sun Nov 11 02:47:54 CET 2007


2007/11/9, Christian Heimes <lists at cheimes.de>:

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

Yes, I saw the change in developers.txt. Now you remind me that I was
going to ask yourself for a presentation. Who're you, what do you do,
where're you from, what do you like, etc. And I hope to meet you in
Chicago!


> 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

If you accept a patch for a bug, doesn't it imply that the bug is real
and that you're accepting the bug?


> 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

I think that they're too many. You shouldn't be thinking too much in
which category to put a bug, or arguing with a coworker for a
category.

Some can clearly be combined (like "later" and "postponed"), some
needs more thought (like "invalid", doesn't it includes "works for
me"?). But it would be great if they're only 5 or 6, and not so vague.

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


More information about the Python-Dev mailing list