On Nov 6, 2012, at 2:44 PM, Andre Klapper aklapper@wikimedia.org wrote:
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/**".
[..] * 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
I'm not sure the extra resolved status makes sense. The issue is clearly not resolved and upstream is already indicated with the upstream keyword.
As for making complex queries, this may take a minute the first time, but doesn't have to be repeated.
The VisualEditor team, for example, has about half a dozen useful queries that are "shared" within the team (any bz user can enable it in their preferences) that the product manager maintains for us. We just click them when we need to know what's up.
And then there is the product-independent query that is useful for developers: "Bugs assigned to me" (that is, with status=ASSIGNED, not just any bug that was by default assigned to you).
Also, why would want to exclude "Waiting for upstream" bugs from triage lists? During a weekly triage I suppose it makes sense to evaluate these as well. Just like one would check up on a patch or the contributor, one would check up on the upstream ticket and maybe poke someone there.
-- Krinkle