Issue 12682: Meaning of 'accepted' resolution as documented in devguide (original) (raw)

Issue12682

process

Created on 2011-08-02 15:07 by r.david.murray, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (22)
msg141568 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2011-08-02 15:07
The devguide documents the 'accepted' resolution as follows: Submitted patch was applied, still needs verifying (for example by watching the buildbots) that everything went fine. At that point the resolution should be set to fixed and the status changed to closed. I've never run into this usage while working with the tracker. I *have* seen people set 'accepted' when they want to indicate that the issue is considered valid to be fixed, or that a feature request has been accepted but there's no patch ready for commit yet. Formally I believe that the 'accepted' resolution is for committed feature requests (since "fixed" doesn't make English sense in that context). Any other use is creative license :)
msg141572 - (view)	Author: Ross Lagerwall (rosslagerwall)	Date: 2011-08-02 16:32
> Formally I believe that the 'accepted' resolution is for committed feature requests That's what I also thought originally. Perhaps this should be discussed on Python-Dev to see what people think it should mean?
msg141580 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2011-08-02 20:26
I say just go ahead and change it. I was probably just thinking how I wish we would use it when I wrote that.
msg141586 - (view)	Author: Senthil Kumaran (orsenthil) *	Date: 2011-08-02 23:49
I propose that we remove 'accepted' as the meaning seems ambiguous and it is of little practical (/tracking) use.
msg141589 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2011-08-03 00:26
It is not ambigous. As I said, bugs are fixed, feature requests are accepted.
msg141590 - (view)	Author: Senthil Kumaran (orsenthil) *	Date: 2011-08-03 01:15
I thought "fixed" was enough. A kind of binary state where we say, okay we have it and otherwise no, we don't. I know for feature requests the terminology does not make sense, but I believe I have worked with bug trackers where fixed was the ultimate state where a particular change (be a bug-fix or a feature request) was in the code. Well, as long as it is helpful, I am fine with it, but too many options can confuse (just as 'accepted' did) and it will be helpful to prune down some.
msg141600 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2011-08-03 05:31
The "Accepted" Resolution was copied from SF. I recall seeing documentation on SF for the resolutions, but can't find that anymore. I also recall that on SF, the "accepted" resolution was used to indicate that a patch was accepted (be it a bug fix or a feature request), and also in combination with the "open" status (in the sense of an "approved" resolution, also).
msg141681 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2011-08-05 20:00
Adding a feature 'fixes' the deficiency of its absence. I personally have no use for 'accepted' and find it ambiguous. My best understanding is what David has seen (accepted in principle).
msg141711 - (view)	Author: Petri Lehtinen (petri.lehtinen) *	Date: 2011-08-06 06:30
Terry J. Reedy wrote: > Adding a feature 'fixes' the deficiency of its absence. I personally > have no use for 'accepted' and find it ambiguous. My best > understanding is what David has seen (accepted in principle). Ditto. Having separate resolutions for bugs and features makes it harder to find all issues that have been closed as "bug fixed or feature accepted", because you cannot select multiple resolutions when searching. With one resolution, you can simply search for "fixed" issues. If you only want to find feature requests that were accepted, search for type=feature and resolution=fixed.
msg141716 - (view)	Author: Ezio Melotti (ezio.melotti) *	Date: 2011-08-06 12:48
FWIW that would be fine with me. Even if there's nothing broken in a feature request, "fixed" applied to feature could mean "the lack of this feature has been fixed". If the issue is valid, one can say so in a message without marking it as 'accepted'.
msg141755 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2011-08-07 22:52
Well, as long as 'accepted' is under 'resolution', I'm likely to keep using it for feature requests, I suppose because I'm too much of a precisonist. If someone wants to re-engineer the interface, that would be fine with me :) I personally don't mind other uses, nor do I find myself searching on resolutions.
msg141767 - (view)	Author: Senthil Kumaran (orsenthil) *	Date: 2011-08-08 10:50
R. David Murray wrote: > If someone wants to re-engineer the interface, that would be fine with me :) Does that mean, that if vote for removing the 'accepted' keyword it becomes an issue for the meta-tracker?
msg141774 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2011-08-08 12:49
I think we've moved from discussing a documentation issue to discussing a procedural issue in the development process. I'm not sure what forum that belongs in, though I believe in the past we have used tracker-discuss for that. That said, I'm really fine with whatever is decided, and don't think it is that big a deal in any regard.
msg141789 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2011-08-08 15:56
When we’ve talked about that a few times these last months on the ML or on IRC, the outcome was that accepted means patch is accepted, not bug report is valid. I’ve never seen accepted used to mean that a feature request is closed; I use fixed for solved bugs and added features alike and don’t see a problem with it.
msg141791 - (view)	Author: Ezio Melotti (ezio.melotti) *	Date: 2011-08-08 16:00
"patch accepted" can be marked with the "commit review" stage. That should mean "the patch is ready to go in, after a last quick review by the committer that will apply it", even though I've seen it used as "I made the commit but I'm leaving this open until I'm sure everything still works".
msg141795 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2011-08-08 17:51
Changing the dev guide, which I think is definitely needed, is an issue for this tracker. Changing the tracker is an issue for the meta-tracker. Discussing a change might be an issue for python-dev. I was under the impression once that the tracker fields were going to be reviewed last summer, before the dev guide was written. This could still happen any time.
msg141806 - (view)	Author: Senthil Kumaran (orsenthil) *	Date: 2011-08-09 02:29
RDM, yes, unfortunately the direction of the discussion changed from documentation issue to a process one. Instead of diverting further into catch all discussion about process/tracker, it would be good idea to settle this one. Your points definitely counts as you raised the issue and have experience in dealing with tracker states. What would you suggest?
msg142442 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2011-08-19 13:15
I would say I find "accepted" little useful in practice. Removing it would avoid the confusion with its various (intended or not) meanings.
msg142443 - (view)	Author: Ezio Melotti (ezio.melotti) *	Date: 2011-08-19 13:16
+1 Martin, should we convert all the "accepted" to "fixed" before removing it?
msg142491 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2011-08-19 19:27
Only if the issue is closed, so that it actually means 'fixed'. Otherwise, just delete it. The following data suggests to me that 'accepted' is a de facto synonym for 'fixed' and therefore useless and might as well be removed. N Issue category 3290 fixed 68 open 3219 closed 354 feature request (and closed) 302 behavior 126 other type 2437 type not specified 346 documentation component (and type not specified) 679 library component The type field has been, at least in the past, greatly underused. But of the last 679, only 27 were in the last 3 years.
msg142495 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2011-08-19 21:09
> Martin, should we convert all the "accepted" to "fixed" before removing it? That's not strictly necessary. It would only be retired (roundup does not support true removal), and as such would then still show up in issues that currently use it, but not show up elsewhere anymore.
msg142497 - (view)	Author: Ezio Melotti (ezio.melotti) *	Date: 2011-08-19 21:15
OK, I removed the resolution and its documentation from the devguide in 3f4710b6baf9.