Closed
Bug 65388
Opened 24 years ago
Closed 8 years ago
Make it possible to query for open bugs with an inactive target milestone
Categories
(Bugzilla :: Query/Bug List, enhancement, P4)
Bugzilla
Query/Bug List
Tracking
()
RESOLVED
FIXED
People
(Reporter: CodeMachine, Assigned: mail)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
dylan
:
review+
|
Details | Diff | Splinter Review |
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?
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.
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.
Reporter | ||
Updated•24 years ago
|
Whiteboard: 3.0 → 3.2
Comment 4•24 years ago
|
||
moving to real milestones...
Whiteboard: 3.2
Target Milestone: --- → Bugzilla 3.2
Comment 5•23 years ago
|
||
-> Bugzilla product
Assignee: tara → justdave
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
Version: other → unspecified
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
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 2.20
Updated•20 years ago
|
Assignee: justdave → erik
Component: Administration → Whining
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
Updated•18 years ago
|
Assignee: erik → whining
![]() |
||
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.
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.
![]() |
||
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.
Assignee: whining → query-and-buglist
Component: Whining → Query/Bug List
Summary: Whine if bug targetted for an old milestone. → Make it possible to query for open bugs with an inactive target milestone
![]() |
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?
Flags: needinfo?
![]() |
Assignee | |
Updated•10 years ago
|
Flags: needinfo?(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
Flags: needinfo?(dkl)
![]() |
Assignee | |
Updated•9 years ago
|
Assignee: query-and-buglist → bugzilla
Status: NEW → ASSIGNED
![]() |
Assignee | |
Comment 15•9 years ago
|
||
I'm sure I've missed something in this patch, but don't know what it is yet :)
Attachment #8638528 -
Flags: review?(dylan)
![]() |
Assignee | |
Comment 16•9 years ago
|
||
Attachment #8638528 -
Attachment is obsolete: true
Attachment #8638528 -
Flags: review?(dylan)
Attachment #8638533 -
Flags: review?(dylan)
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. :)
Attachment #8638533 -
Flags: review?(dylan) → review+
![]() |
Assignee | |
Comment 18•8 years ago
|
||
To github.com:bugzilla/bugzilla.git c7b85d8..a460196 master -> master
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•