On Tue, 27 Apr 2010 10:34:16 -0500, Daniel Stutzbach wrote:

Thanks. Is there a document that describes the meaning of all of the different fields in the bug tracker?

I've read http://www.python.org/dev/workflow/, but it doesn't cover everything.

I think it is on Brett's list to update that doc, but maybe we should help him out :). Can you list what's missing? We should fill in the gaps. -- R. David Murray www.bitdance.com

The page doesn't document the Resolution or Status fields.

The resolutions are the same as the ones on SourceForge. You only have resolutions on closed issues, and they explain why an issue was closed. If any specific one is unclear in that context, please be more specific. On the status, I hope open/closed are clear, and these are the ones you should be using. Pending is meant as "auto-close in two weeks unless there is follow-up", and its unimplemented. For languishing, click on the label "Status" left of the field.

For the Keywords field, the page only documents the "easy" keyword.

So which ones you don't understand?

Also, some of the headings in the page are enclosed in square brackets, while others are not. It's not clear to me what the brackets are intended to designate.

Not sure what this is referring to - I don't see any square brackets. Regards, Martin

On Thu, 29 Apr 2010 14:11:57 -0400, Terry Reedy 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

On Fri, 30 Apr 2010 07:17:02 +1000, Nick Coghlan wrote:

R. David Murray wrote:

...

On Thu, 29 Apr 2010 14:11:57 -0400, Terry Reedy 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.

Note that I'll occasionally use "pending" to mean "committed to at least one branch, still need to port/block remaining branches". (e.g. I did it this week, since 2.7b2 was higher priority than the other branches which don't have near term binary releases coming up).

I've seen others use it that way as well.

Yes, I have noticed that several people do this. This will stop working if we implement autoclose. Other people just leave the issue open and change the targeted versions instead. -- R. David Murray www.bitdance.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote:

...

...

You only have resolutions on closed issues, Only for 'closed' or also for 'pending' and 'languishing'?

Probably for all of them. I don't understand languishing, though (neither as an English word, nor as a status).

...

'Languishing' is new (its first use was two months ago). Is it a form of 'open' or of 'closed'?

I have no idea.

Open, definitely: it implies "suffering due to neglect", combining senses 2 and 5 from this page: http://en.wiktionary.org/wiki/languish Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvaAxUACgkQ+gerLs4ltQ6lIwCePWePnXRfHbvRcx3Ih6rV7AhQ qiYAn2V5yR/PjIb+WSr/ILhO5p3WGHoO =XWHS -----END PGP SIGNATURE-----