Bug 207274

Summary:	Request: WONTFIX status
Product:	Services	Reporter:	Dag-Erling Smørgrav <des>
Component:	Bug Tracker	Assignee:	Bugmeister <bugmeister>
Status:	Open ---
Severity:	Affects Some People	CC:	emaste
Priority:	---	Keywords:	dogfood, easy, needs-qa
Version:	unspecified
Hardware:	Any
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206887

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

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.

Comment 3 Mark Linimon freebsd_committer

2024-03-30 02:21:27 UTC

^Triage: reassign.