65388 - Make it possible to query for open bugs with an inactive target milestone

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement, P4)

Description

[Matthew Tuck [:CodeMachine]]

If an open bug is targetted for an old milestone, we should whine occasionally.

One slight problem is that the '---' milestone might have the earliest sortkey,
and hence be considered chronologically.

Maybe we could hardcode in '---', I think that's a reasonable idea.

This would be per-installation or (better) per-product prefable, I don't think
per-component is useful, but who knows?

Comment 1

[Matthew Tuck [:CodeMachine]]

We could suppress this check for the default milestone, which you would expect
'---' be.

But then you might also want a global check to make sure the default milestone
has not expired.

I suggest it makes good sense to hardcode '---' into all installations.

Comment 2

[Matthew Tuck [:CodeMachine]]

I suggest the report get run each time the current milestone gets changed for a
product, and then weekly.

Comment 3

[Matthew Tuck [:CodeMachine]]

3.0 Issue - This can cause bugs to get lost.

Comment 4

[Dave Miller [:justdave]]

moving to real milestones...

Comment 5

[Dave Miller [:justdave]]

-> Bugzilla product

Comment 6

[Boris 'pi' Piwinger]

I was just about to file a bug asking to reset target milestones in the past.
What is the use of having a target which is not reachable? There could be two
solutions to this:

1) Reset missed targets to --- (without spamming everybody on those bugs).
or
2) Change missed targets to "missed" (again without mailing).

2) would still allow to whine about it;-)

Why I want this? Because if you want to find out about missed targets, you have
to make an absurd complicated query (which also makes the form messier than
neeeded):
http://bugzilla.mozilla.org/buglist.cgi?target_milestone=M1&target_milestone=M10&target_milestone=M11&target_milestone=M12&target_milestone=M13&target_milestone=M14&target_milestone=M15&target_milestone=M16&target_milestone=M17&target_milestone=M18&target_milestone=M2&target_milestone=M3&target_milestone=M4&target_milestone=M5&target_milestone=M6&target_milestone=M7&target_milestone=M8&target_milestone=M9&target_milestone=mozilla0.6&target_milestone=mozilla0.8&target_milestone=mozilla0.8.1&target_milestone=mozilla0.9&target_milestone=mozilla0.9.1&target_milestone=mozilla0.9.2&target_milestone=mozilla0.9.3&target_milestone=mozilla0.9.4&target_milestone=mozilla0.9.5&target_milestone=mozilla0.9.6&target_milestone=mozilla0.9.7&target_milestone=mozilla0.9.8&target_milestone=mozilla0.9.9&target_milestone=mozilla1.0&target_milestone=mozilla1.0.1&target_milestone=mozilla1.0.2&target_milestone=mozilla1.0.3&target_milestone=mozilla1.1alpha&target_milestone=mozilla1.1beta&target_milestone=mozilla1.1final&target_milestone=mozilla1.2alpha&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

Should I file a new bug on this?

pi

Comment 7

[Dave Miller [:justdave]]

This is now possible as a site-configuration issue as of bug 185090 landing. 
The current implementation will, however, require the admin to continually
refine the query to decide which the old milestones are as each passes.  Leaving
this but open for now because of the dependency on bug 218036, which implies we
want a "pronoun" available for the whining which references the new current
milestone field in each product that's being created in bug 218036.

Comment 8

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 9

[Frédéric Buclin]

This doesn't scale well for projects supporting several branches, such as Firefox or even Bugzilla. The definition of "current milestone" is vague in these cases. And you can already set your queries yourself and use them to get whine mail. WONTFIX IMO.

Comment 10

[Matthew Tuck [:CodeMachine]]

This is more about the generation of a report than about the mechanism used to determine whether a milestone is old.  But I understand that nowadays there is an "inactive milestone" feature, so this would easily work by generating a whine about open bugs with an inactive milstone.

Comment 11

[Frédéric Buclin]

(In reply to Matthew Tuck [:CodeMachine] from comment #10)
> there is an "inactive milestone" feature, so this would easily work by
> generating a whine about open bugs with an inactive milstone.

And so this is no longer a bug/request for the whining system itself but a request for the searching system.

Comment 12

[Simon Green]

I guess the best way to solve this is to do it in the custom search, and have an 'is active' and 'is not active' option. Obviously setting is active to something that doesn't have activeness (e.g. comments) would result in an error.

Thoughts?

Comment 13

[Frédéric Buclin]

(asking nobody specifically is useless)

Comment 14

[David Lawrence [:dkl]]

I do not see why this could not be a new operator in the custom search section of advanced search. I do not personally have time right now to look into this but I think it is a good idea.

dkl

Comment 15

[Simon Green]

Attachment: bug65388-v1.patch

I'm sure I've missed something in this patch, but don't know what it is yet :)

Comment 16

[Simon Green]

Attachment: bug65388-v1.patch

Comment 17

[Dylan Hardison [:dylan] (he/him)]

Comment on attachment 8638533 [details] [diff] [review]
bug65388-v1.patch

This was really really difficult to test, partly because we don't have a testing corpus. (I'm working with someone on that, but it's not ready yet).

That said, I have tested this on versions and milestones and read over the code. This is pretty good work, Simon. I'm sorry it took a year to review it. :)

Comment 18

[Simon Green]

To github.com:bugzilla/bugzilla.git
   c7b85d8..a460196  master -> master