Matthew Tuck [:CodeMachine] Reporter
	Description • 24 years ago

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?

	Matthew Tuck [:CodeMachine] Reporter
	Comment 1 • 24 years ago

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.

	Matthew Tuck [:CodeMachine] Reporter
	Comment 2 • 24 years ago

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

	Matthew Tuck [:CodeMachine] Reporter
	Comment 3 • 24 years ago

3.0 Issue - This can cause bugs to get lost.

	Dave Miller [:justdave]
	Comment 4 • 24 years ago

moving to real milestones...

	Dave Miller [:justdave]
	Comment 5 • 23 years ago

-> Bugzilla product

	Boris 'pi' Piwinger
	Comment 6 • 22 years ago

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

	Dave Miller [:justdave]
	Comment 7 • 20 years ago

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.

	Dave Miller [:justdave]
	Comment 8 • 20 years ago

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.

	Frédéric Buclin
	Comment 9 • 15 years ago

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.

	Matthew Tuck [:CodeMachine] Reporter
	Comment 10 • 15 years ago

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.

	Frédéric Buclin
	Comment 11 • 13 years ago

(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.

	Simon Green Assignee
	Comment 12 • 11 years ago

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?

	Frédéric Buclin
	Comment 13 • 10 years ago

(asking nobody specifically is useless)

	David Lawrence [:dkl]
	Comment 14 • 10 years ago

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

	Simon Green Assignee
	Comment 15 • 9 years ago

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

	Dylan Hardison [:dylan] (he/him)
	Comment 17 • 8 years ago

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. :)

	Simon Green Assignee
	Comment 18 • 8 years ago

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