Hi,
[See my comments inline]
Quim: Thanks for the wonderful analogy and bringing this up again.
The question boils down to:
How and why do people use RESOLVED LATER?
The same topic was discussed one year ago in
http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056583.html and
other projects had similar problems with RESOLVED LATER, e.g. see
http://www.eclipsezone.com/eclipse/forums/t83053.html
Upstream Bugzilla developers removed RESOLVED LATER for Bugzilla ⪖3.0:
https://bugzilla.mozilla.org/show_bug.cgi?id=13534
> On Nov 6, 2012, at 12:02 AM, Nabil Maynard <nadr...@gmail.com> wrote:
> > 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?
One posting from last year's thread also stated "Currently the LATER
acts as a blackhole and there is no structured process to re-evaluate
these kind of bugs." (If importing from the compressed archives wasn't
broken I could even tell you who wrote that.)
On Tue, 2012-11-06 at 02:24 +0100, Krinkle wrote:
> 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/**".
+1.
My interpretation of potential meanings from the top of my head:
* Meaning of "priority = lowest" (and potentially "Target
Milestone = Mysterious Future" if TMs were really used). Using
this obviously would not remove the report from being listed in
the search results for open tickets, and I assume that people
are lazy to run more complicated searches in Bugzilla to exclude
those. Or rephrase this to "Bugzilla makes it hard to run useful
queries" if you think that you're not lazy, but that it's the
technology's fault.
* Meaning of "RESOLVED WONTFIX". But as that sounds harsh the
original reporter could disagree and start discussing, and
discussing takes time the WONTFIXer would like to avoid
spending. Social problem that requires explaining well why
WONTFIX was set.
* Meaning of "depends on UPSTREAM". We won't fix it ourselves but
wait for an upstream fix. We won't backport the upstream fix but
wait until we upgrade servers to an entire new Ubuntu version
which provides a newer package that includes the fix. The Mer
project uses "RESOLVED WAITING_FOR_UPSTREAM" for this.
If I miss meanings, please provide them.
Currently I'm in favor of killing RESOLVED LATER (which requires
retriaging these tickets) and introducing a RESOLVED
WAITING_FOR_UPSTREAM status for the latter case.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
