On Nov 5, 2012, at 11:54 PM, Platonides Platonides@gmail.com wrote:
How many of them depend on action from somebody else? (eg. upstream fixing its tool)
Of course, if we are waiting for upstream, it should list the upstream bug id, have upstream keyword, someone actually noticing when it's fixed, etc. but those are form issues, not the status. (and yes, 'resolved' is a misnomer)
On Nov 6, 2012, at 12:02 AM, Nabil Maynard nadreck@gmail.com wrote:
LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
While we could arguably just dump both situations into WONTFIX, I think that would muddy the triage process pretty heavily, making it more difficult to track bugs we intend to revisit.
That said, it IS easy for LATER to become a procrastination paradise, where it gets resolved and then never thought of again. Would it be worthwhile to set up an automated notice when a LATER bug ages past a certain date (say, a month without being touched), instead of axing the resolution?
I agree we should drop this status.
We have the following indications that should be used instead:
* blockers / dependencies * status ASSIGNED * keyword upstream * priority low or lowest * severity minor * or, resolved-wontfix if that is the case.
Using LATER in any of these cases only causes the bug to be lost end omitted from searches and lists.
I don't think it depends on the project, it depends on the user making the query not knowing how to utilise the above factors.
If one wants to generate a list to work off of that doesn't contain any of these, exclude them in the search parameters as desired. Don't stamp LATER on the bugs to make it fit the lazy search that only omits "RESOLVED/**".
@AndreKlapper: What do you think?
-- Krinkle