Facundo Batista wrote:
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
It only tells you that a resolution was reached, not what that
resolution was.
"Resolution: resolved" is meaningless repetition - what matters is *how*
the issue was resolved, and simply saying 'resolved' doesn't tell
anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are
resolutions since they give you some idea of how the issue was resolved
- the only thing missing is a definition of just how they should be used.*
Now, dropping 'later', 'postponed' and 'remind' from the list of
available resolutions is something I could wholeheartedly support. If we
want to postpone something to a later release, we should put an
appropriate entry in the version list.
My stab at definitions for the other resolutions:
# Feature request resolutions
accepted - feature request accepted (possibly via attached patch)
rejected - feature request rejected
# Bug report resolutions
fixed - reported bug fixed (possibly via attached patch)
invalid - reported behaviour is intentional and not a bug
works for me - bug could not be replicated from bug report
out of date - bug is already fixed in later Python version
wont fix - valid bug, but not fixable in CPython (very rare)
# Common resolutions
duplicate - same as another issue (refer to other issue in a comment)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
