Closed
Bug 13534
Opened 25 years ago
Closed 18 years ago
REMIND and LATER considered harmful.
Categories
(Bugzilla :: Administration, task, P3)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.0
People
(Reporter: CodeMachine, Assigned: pjdemarco)
References
Details
Attachments
(1 file, 5 obsolete files)
2.80 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
I think that we should endeavour to remove REMIND and LATER from Bugzilla. I believe that they achieve more harm than good. There are many disadvantages: (a) They can easily not appear as queries. After all, they are _unresolved_. (b) Effort to reopen, resulting in comments/activity which clutter the bug report. (c) They are usually set by Netscape employees and hence imply Netscape's agenda for what will go in. Mozilla, at least, is a open project, where anyone can contribute. So, what's the alternative? The obvious answer is, the milestone. Remind can already be handled by moving the bugs to a later milestone where they need to get reevaluated. Remind could even get turned into a bug flag (see bug #11155). For LATER, there needs to be an "No Target" milestone. This means that there is currently no plan for implementation, but it has been considered, and hence won't appear on groups' new bugs radar (ie having a blank milestone, which might be renamed to "To Be Considered"). This would require a little modification of queries by Netscape employees to exclude untargetted bug reports, but they generally know how to use Bugzilla. It is a lot more important that Bugzilla newbies can quickly find the issues that do not have a target date and they should help out on, and point (a) can prevent this. This, combined with the introduction of assigning to "nobody@mozilla.org", covers all the issues that I know of. Note that this works just as well for closed or in-house projects that use Bugzilla.
Remind and later could just be added to the milestone list (and removed elsewhere). This seems like a good idea.
Reporter | ||
Comment 2•25 years ago
|
||
I think remind is unnecessary, and "No Target" is a better, although longer name for "Later".
Comment 3•25 years ago
|
||
Here's a more general solution: merge the Status and Resolution fields. * Have Status be one of {New, Assigned, Reopened, Fixed, Later, Wontfix, Invalid, Worksforme, Duplicate, Closed}. * Have a single `Verified' checkbox. Whenever the bug's Status is changed, `Verified' is unchecked, so that the new status can be verified by someone else (usually a QA person). * `New' + `Verified' == triaged. This makes things easier for people like me who spend time triaging bugs, to tell which bugs haven't been processed yet. * If `Assigned', a bug can only be `Verified' by the person who it is assigned to. This is equivalent to accepting the bug, so the `Accept bug' control is no longer needed. Elegant, eh? * `Remind' and `Later' are nuked, as explained by matty.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P5
Comment 5•25 years ago
|
||
Leaving this bug open, but be warned I'm not likely to do anything about it. People making their own installation of bugzilla can customize away REMIND and LATER.
Comment 6•25 years ago
|
||
This is really a mozilla.org policy issue. What is the proper forum for resolving it?
Reporter | ||
Comment 8•25 years ago
|
||
True, but the "No Target"/"To Be Determined" milestone separation is something that should be Bugzilla standard I think, and if not implemented first, the LATER removal will be shot down in flames.
Comment 9•25 years ago
|
||
Every bug should either have a target or be closed WONTFIX. It would be reasonable to have a target of 5.1M1 for things not expected to be fixed in 5.0.
Reporter | ||
Comment 10•25 years ago
|
||
Every bug maybe, but what about enhancements? There are lots in this system.
Reporter | ||
Comment 11•25 years ago
|
||
MPT, one problem with your proposal is that Closed loses the Fixed/WontFix/Invalid/etc. resolution. Have you filed this separately yet?
Comment 12•25 years ago
|
||
Enhancements without assigned resources are now regularly left open and assigned to nobody@mozilla.org.
Reporter | ||
Comment 13•25 years ago
|
||
Yes, a lot are, but not all, and I'm not sure everyone would want to do it this way. If the vast majority of developers were happy with this I would be too.
Comment 14•25 years ago
|
||
matty: No, I'm still thinking about how to represent the unverified/verified scheme from a user's point of view, in order to make it obvious what it's for. Interestingly, Bugzilla's the extra UNCONFIRMED status was introduced after my suggestion, but it provides another example of something that could be simplified using the verified/unverified scheme -- by having NEW -verified and NEW +verified. However, the simple fix for this bug is the same as I described in my earlier suggestion: simply to move REMIND and LATER from the Resolution field into the Status field. (I have to admit I don't follow the logic behind the existence of CLOSED -- it seems to me to be based on a fallacious assumption that bugs can't possibly regress after a particular version of the product has been shipped.)
Reporter | ||
Comment 15•25 years ago
|
||
Not suprisingly, I found someone the other day whose most popular votes query didn't have REMIND and LATER.
Comment 16•25 years ago
|
||
tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Comment 17•24 years ago
|
||
To fix this, query for *browser* bugs marked as remind/later and click "change several bugs at once", select the "future" milestone, and add a comment like "replacing remind/later resolutions with future milestone." Then do similar things for other products, which have different milestone systems.
Reporter | ||
Comment 18•24 years ago
|
||
I'd like to see this happen in 2.12 for new installations. I don't expect it'd be much effort. I'd like it if other installations don't repeat mozilla.org's mistakes.
Whiteboard: 2.12
Comment 19•24 years ago
|
||
bugzilla.mozilla.org currently has 239 bugs that still have REMIND or LATER resolutions. Do we need to force them to fix those before this gets implemented? Are they willing to do it this way?
Comment 20•24 years ago
|
||
This one is a bit of a pain to change being that it's an enum. I suppose we could just change the line at: http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/checksetup.pl#626 REMIND also shows up at: http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/checksetup.pl#1638 (where the UNCONFIRMED status gets added). I haven't looked at this second chunk of code to see what impact removing REMIND and LATER from it would have. Changing the first line shouldn't have any ill side effects (as it is only run if the "bugs" table doesn't exist.
Reporter | ||
Comment 21•24 years ago
|
||
I wanted to change this for the default setting, not for existing installations, so it shouldn't matter what mozilla.org is doing. I don't know of any systems that use this other than mozilla.org (who are phasing it out), which suggests that: (a) some installations know it's unnecessary and remove it (b) the rest don't need it anyway and we shouldn't encourage them to do so Wrt the effort required to change this, I would have thought it would be easier, but it seems maybe it isn't if it's in code, although if it's only in checksetup.pl it might be easy - I can't tell. We might want to let this slide for 2.12, and at some stage should let resolutions be specified by the admin (in a table) rather than hardcoded.
Reporter | ||
Comment 23•24 years ago
|
||
At least 3.0 fix: Should redesign so that the admin can specify resolutions. Dupe is probably a special case as it is universally applicable and has special functionality. Also need to update bug_status.html documentation appropriately.
QA Contact: matty
Whiteboard: 3.0
Comment 24•24 years ago
|
||
Moving to real milestones...
Whiteboard: 3.0
Target Milestone: --- → Bugzilla 3.0
Comment 25•24 years ago
|
||
Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it really was spot on. Note: I may end up pushing some of these bugs back to 3.2, we'll see. However, I believe all these bugs should just fall out of the redesign. Let's hope I'm right! (Note: I'm also resetting the priority field to "---" so that I can retriage any that I consider important or likely to be dropped.)
Assignee: tara → ian
Component: Bugzilla → Bugzilla 3
Priority: P5 → --
Reporter | ||
Comment 26•23 years ago
|
||
Just thinking - we don't need to remove REMIND and LATER from the schema to do this in BZ2. All we really need to do is have a param called remindandlater. If on, people can resolve bugs and REMIND and LATER, if off, they can't but existing REMIND and LATER bugs can still exist. I'm thinking we should just make this off by default but I guess we're gonna suprise some admins if we don't ask. Something like: --- The resolutions REMIND and LATER are deprecated. It is suggested you use a target milestone to mean "Future" instead, and that you remove the REMIND and LATER resolutions from your installation. If you choose to remove these resolutions, existing bugs will continue to have these resolutions, but users will be unable to mark new bugs as REMIND or LATER. Remove them (Y/N)? --- If we are creating a new database, or if we don't find any bugs with these resolutions, just turn the parameter off.
Comment 27•23 years ago
|
||
The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.
Component: Bugzilla 3 → Bugzilla
Reporter | ||
Comment 28•23 years ago
|
||
I am working on a solution for this by implementing customised resolutions over at bug #94534.
Reporter | ||
Comment 29•23 years ago
|
||
As such, taking this ...
Assignee: ian → matty
Priority: -- → P3
QA Contact: matty → jake
Target Milestone: Bugzilla 3.0 → Bugzilla 2.16
Reporter | ||
Updated•23 years ago
|
Depends on: bz-custres
Reporter | ||
Comment 30•23 years ago
|
||
Moving to new Bugzilla product ...
Assignee: matty → justdave
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
QA Contact: jake → matty
Version: other → 2.13
Reporter | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•23 years ago
|
QA Contact: matty → jake
Comment 32•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 33•22 years ago
|
||
Are there any news regarding this bug? (Last comment is from November 2001)
Comment 34•22 years ago
|
||
They've already been removed (via local hack) at mozilla.org :-) Someone was going to do custom resolutions at some point, at which time this would get removed from the defaults on new installations and existing installations could feel free to delete them (see the dependency). But I haven't seen any action there in a while either. Matty?
Comment 35•21 years ago
|
||
Taking Jake's bugs... his Army Reserve unit has been deployed.
QA Contact: jake → justdave
Comment 36•21 years ago
|
||
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 37•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
Comment 38•19 years ago
|
||
Since we continue to release bugzillas with this embarassing bug, and bug 94534 doesn't seem to be going anywhere. So attached are some patches. They don't handle the upgrade path for reports and such; I'm not sure what that would look like. But applied, they'd at least remove them from fresh installs, which seems like a step. [And yes, these patches are brain-dead simple, but... something has to jumpstart this.]
Comment 39•19 years ago
|
||
Probably worth pointing out that we basically don't even document REMIND + LATER, just one note in the dia diagram. If this group of patches is not accepted, I'll submit a patch to document that you should remove these immediately after install.
Comment 40•19 years ago
|
||
Comment 41•19 years ago
|
||
Note: * doesn't attempt to handle the upgrade case (hence I assume it will be rejected.) * this doesn't attempt to change how the collectstats stuff is configured- AFAICT, if these fields don't exist, things will fail quietly (though I have only read the code, and not tested it)
Comment 42•19 years ago
|
||
![]() |
||
Updated•19 years ago
|
Assignee: mattyt-bugzilla → administration
Status: ASSIGNED → NEW
QA Contact: justdave → default-qa
Target Milestone: Bugzilla 2.22 → ---
![]() |
||
Comment 43•18 years ago
|
||
Now that bug 94534 is fixed, it should be easy to remove these resolutions so that they do not appear by default for new installations.
Target Milestone: --- → Bugzilla 3.0
Assignee | ||
Comment 44•18 years ago
|
||
Attachment #189061 -
Attachment is obsolete: true
Attachment #189062 -
Attachment is obsolete: true
Attachment #189063 -
Attachment is obsolete: true
Attachment #189064 -
Attachment is obsolete: true
Attachment #233867 -
Flags: review?
Attachment #233867 -
Flags: review? → review?(mkanat)
Attachment #233867 -
Flags: review?(mkanat) → review?(LpSolit)
Comment 45•18 years ago
|
||
Comment on attachment 233867 [details] [diff] [review] new install defaults REMIND and LATER are removed. On its own, this looks good from here. I thought through this asking myself - what conditions could possibly break this removal... Since we're off ENUM types, the only possible conflict I could see is if someone is trying to merge legacy Bugzilla installations and RESOLVED/LATER or REMIND was used there. It wouldn't hurt to include documentation somewhere in the release notes about this.
Attachment #233867 -
Flags: review+
![]() |
||
Comment 46•18 years ago
|
||
Comment on attachment 233867 [details] [diff] [review] new install defaults REMIND and LATER are removed. You also have to fix contrib/gnats2bz.pl @ line 652: $resolution = "LATER";, docs/images/bzLifecycle.xml @ line 1123: LATER#</dia:string> and template/en/default/global/field-descs.none.tmpl @ 94: "LATER" => "LATER",. That's for LATER. About REMIND, you have to fix the same places, except contrib/gnats2bz.pl which doesn't use it. Else your patch works fine. I just tested it on a fresh installation.
Attachment #233867 -
Flags: review?(LpSolit) → review-
![]() |
||
Comment 47•18 years ago
|
||
About contrib/gnats2bz.pl, you should probably force it to make sure that LATER is a valid resolution, and if not, use another valid one.
Status: NEW → ASSIGNED
Assignee | ||
Comment 48•18 years ago
|
||
changes made per communication on IRC
Attachment #233867 -
Attachment is obsolete: true
Attachment #236598 -
Flags: review?(LpSolit)
![]() |
||
Comment 49•18 years ago
|
||
Comment on attachment 236598 [details] [diff] [review] with some extra files changed r=LpSolit
Attachment #236598 -
Flags: review?(LpSolit) → review+
![]() |
||
Updated•18 years ago
|
Flags: approval?
Updated•18 years ago
|
Flags: approval? → approval+
![]() |
||
Comment 50•18 years ago
|
||
Checking in Bugzilla/DB.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB.pm,v <-- DB.pm new revision: 1.85; previous revision: 1.84 done Checking in contrib/gnats2bz.pl; /cvsroot/mozilla/webtools/bugzilla/contrib/gnats2bz.pl,v <-- gnats2bz.pl new revision: 1.8; previous revision: 1.7 done Checking in docs/images/bzLifecycle.xml; /cvsroot/mozilla/webtools/bugzilla/docs/images/bzLifecycle.xml,v <-- bzLifecycle.xml new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/global/field-descs.none.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/field-descs.none.tmpl,v <-- field-descs.none.tmpl new revision: 1.17; previous revision: 1.16 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 51•18 years ago
|
||
Added to relnotes in bug 349423. Please let me know if I missed any critical information about this bug in the release notes.
Keywords: relnote
You need to log in
before you can comment on or make changes to this bug.
Description
•