Bug 207274 - Request: WONTFIX status
Summary: Request: WONTFIX status
Status: Open
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Kubilay Kocak
URL:
Keywords: dogfood, easy, needs-qa
Depends on:
Blocks:
 
Reported: 2016-02-17 12:20 UTC by Dag-Erling Smørgrav
Modified: 2016-02-17 18:32 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dag-Erling Smørgrav freebsd_committer 2016-02-17 12:20:44 UTC
I have come across several PRs where none of the existing statuses seem to fit.  For instance, in #206887, the issue is real, which eliminates "Works As Intended", "Not Enough Information", "Unable to Reproduce" and "Not A Bug"; it is not a "DUPLICATE" and there has been no "Feedback Timeout"; and it was certainly not "FIXED" since I resolved it by removing the broken script instead of updating it to the latest version from upstream, which works.  This leaves "Overcome By Events" (not really, since the event in question was a direct result of the PR, not something that happened while it was languishing in the queue) and "Rejected" doesn't feel right either since it seems to imply that the report itself is worthless, which is certainly not the case.

Could you please add a WONTFIX status for use in situations like this?
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-02-17 15:51:11 UTC
Thanks Des

I'm reviewing the current resolution statuses with a view to replacing them with a more mutually exclusive, intuitive and granular. I'll create a parent issue for this that blocks this issue shortly.

One of those in the firing/replacement line will likely be 'Rejected', which I believe is too overloaded. Something like denied or wontfix is what should replace it. I believe this should cover your case and others in a more suitable way.

Having said that, one of the considerations for any changes to these states (either in name, or meaning) is to maintain as much of the semantics for existing closed bugs, given they have had their resolutions set already. I dont think however this will be an issue for the renaming the rejected state.

In context to the issue you mentioned, the resolution selected can sometimes only make sense depending on the issue "summary" itself.

For instance, 

a) If the issue summary was "Disable broken script", and you removed the script, technically it was fixed (by workaround, potentially until next version).

b) If the summary was "Fix broken script", and you removed the script, Denied/Wontfix may be slightly more accurate.

In this case I would have selected FIXED as you did, given Rejected is overloaded, with an added comment that "the broken script was disabled temporarily as a workaround until the next version is released" so the user was clear on what/why. I see you have done that already
Comment 2 Dag-Erling Smørgrav freebsd_committer 2016-02-17 18:32:53 UTC
(In reply to Kubilay Kocak from comment #1)
> In this case I would have selected FIXED as you did, given Rejected is
> overloaded, with an added comment that "the broken script was disabled
> temporarily as a workaround until the next version is released" so the user
> was clear on what/why.

Yeah, it's not temporary though.  The script is not needed and should have been removed a year ago when I committed r276702.

But thank you for the explanation of your work in progress, I look forward to seeing the finished result.