On Thu, 29 Apr 2010 14:11:57 -0400, Terry Reedy <tjre...@udel.edu> wrote:
> On 4/27/2010 5:14 PM, "Martin v. Loewis" wrote:
> > You only have resolutions on closed issues,
>
> Only for 'closed' or also for 'pending' and 'languishing'?
> If pending were implemented to mean 'auto close in x days', then
> Resolution would need to be set when Status is set to 'pending'.
Definitely. Resolution should always be set for Pending, IMO.
> 'Languishing' is new (its first use was two months ago). Is it a form of
> 'open' or of 'closed'?
Open.
> > and they explain why an issue was closed.
>
> This needs to be explicitly stated in the doc if you want it followed.
>
> In response to my repeating this on the tracker,
> bugs.python.org/issue7511
> R. David Murray said (in part)
> "Some committers have been using 'resolution: accepted' as a way to mark
> issues that are definitely going to be fixed/enhancement added."
>
> This is a different and therefore confusing use of the field and strikes
> me as mostly redundant with the newer Stage field with a value of Needs
> patch or later.
Well, where it gets ambiguous is that the stage can get set to unit
test or patch needed because that's what stage the bug report is in,
without anyone having made a decision as to whether or not the patch will
actually get applied if the patch is completed. So some way of indicating
that the bug/enhancement is 'accepted' and will be applied as soon as it
passes muster seems like a good idea, as opposed to issues where the
evolution of the patch is part of the decision making process as to
whether to accept it or not. I agree that having that be the
'resolution' field is logically and pedagogically incorrect ;)
I've made a proposal (discussed with some of the other triage people)
that would clarify this (and perhaps ultimately lead to the elimination
of the stage field, although I don't mention that idea on the wiki), at:
http://wiki.python.org/moin/DesiredTrackerFeatures
I believe Ezio will be looking at this this summer.
> > If any specific one is unclear in that context, please be more specific.
[...]
> over-complex part. There was a discussion here some time ago on the fine
> distinctions, but I am again fuzzy on 'accepted' versus 'fixed', 'later'
> versus 'postponed', and 'invalid' versus 'works for me'. I have no idea
> when 'remind' would be used (it has only been used 8 times).
In my mind some of these are clear (at least when using the field as
it is labeled: for 'resolution'), but clearly the docs need help.
'accepted' would be for an enhancement (committing an enhancement
doesn't 'fix' anything), while 'fixed' means the bug no longer exists.
'invalid' means that the bug report is just wrong, it's not a bug,
while 'works for me' usually means that we can't reproduce the problem.
I agree that some bugs that get closed 'works for me' really should be
closed using another resolution. I doubt the reverse is true. I suspect
'works for me' gets used sometimes instead of invalid because the closer
isn't sure that everyone on the dev teams shares their opinion that
the bug is invalid or; more often, in cases where "won't fix" would be
more appropriate.
'Accepted' and 'fixed' could be replaced by the single resolution
'committed'. That will eliminate the ambiguity of using 'accepted'
as something other than a resolution. 'Works for me' should probably
be dropped and replaced by "can't reproduce".
'later', 'remind', and 'postponed' all seem too close to be useful
distinctions, and all seem pretty much equivalent to 'languishing'.
IMO only one of the four should be kept. I prefer 'languishing' because
it shows up as an issue count in the weekly summary, and it seems to me to
me that this marking for an issue is more of a status than a resolution.
(That is, 'later', 'remind', and 'postponed' are *not* resolutions,
they are procrastinations, which 'languishing' makes explicit.)
> > For languishing, click on the label "Status" left of the field.
>
> and Keywords. There should also be a pop-up for Resolution.
> And the pop-up tables should also be in the doc.
It would be great if you would open an issue for these suggestions in
the meta-tracker, so that they don't get lost.
If there is no objection to the resolution changes I suggest above, I
can do those. I believe issues closed with those resolutions would keep
them, and that there is a way for someone to mine for them if they ever
wanted to go through and reevaluate them. I could optionally change
all 'accepted' and 'fixed' into 'committed' since that change is pretty
unambiguous, but the others I think should just be left unchanged on
the existing issues unless someone feels moved to change a given issue
by hand.
This would leave us with the following list of resolutions:
committed
out of date
duplicate
can't reproduce
invalid
won't fix
rejected
The only remaining redundancy is "won't fix" versus "rejected", but I
can't think of single word that would cover both cases (we refuse to
fix a bug for various reasons, but we reject an enhancement request).
--
R. David Murray www.bitdance.com
_______________________________________________
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
