Closed Bug 13534 Opened 21 years ago Closed 13 years ago

REMIND and LATER considered harmful.


(Bugzilla :: Administration, task, P3)




Bugzilla 3.0


(Reporter: CodeMachine, Assigned: pjdemarco)




(1 file, 5 obsolete files)

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

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
"", covers all the issues that I know of.

Note that this works just as well for closed or in-house projects that use
Remind and later could just be added to the milestone list (and removed
elsewhere).  This seems like a good idea.
I think remind is unnecessary, and "No Target" is a better, although longer name
for "Later".
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.
I think the comment is orthogonal to this bug.
Priority: P3 → P5
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
This is really a policy issue.  What is the proper forum for
resolving it?
You can try the newsgroup.
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.
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.
Every bug maybe, but what about enhancements?  There are lots in this system.
MPT, one problem with your proposal is that Closed loses the
Fixed/WontFix/Invalid/etc. resolution.  Have you filed this separately yet?
Enhancements without assigned resources are now regularly left open and assigned 
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.
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.)
Not suprisingly, I found someone the other day whose most popular votes query
didn't have REMIND and LATER. is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news:// .)
Assignee: terry → tara
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.
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's
Whiteboard: 2.12 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?
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:

REMIND also shows up at:
(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.
I wanted to change this for the default setting, not for existing installations,
so it shouldn't matter what is doing.

I don't know of any systems that use this other than (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 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.
definitely not for 2.12 at this point
Whiteboard: 2.12
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
Moving to real milestones...
Whiteboard: 3.0
Target Milestone: --- → Bugzilla 3.0
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 → --
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.
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 
Component: Bugzilla 3 → Bugzilla
I am working on a solution for this by implementing customised resolutions over
at bug #94534.
As such, taking this ...
Assignee: ian → matty
Priority: -- → P3
QA Contact: matty → jake
Target Milestone: Bugzilla 3.0 → Bugzilla 2.16
Depends on: bz-custres
Moving to new Bugzilla product ...
Assignee: matty → justdave
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
QA Contact: jake → matty
Version: other → 2.13
Taking (again) ...
Assignee: justdave → matty
QA Contact: matty → jake
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
Are there any news regarding this bug? (Last comment is from November 2001)
They've already been removed (via local hack) at :-)

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?
Taking Jake's bugs...  his Army Reserve unit has been deployed.
QA Contact: jake → justdave
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
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
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
Attached patch patch for docs (obsolete) — Splinter Review
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.
Attached patch patch for localconfig (obsolete) — Splinter Review
Attached patch patch to checksetup (obsolete) — Splinter Review
* doesn't attempt to handle the upgrade case (hence I assume it will be
* 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)
Attached patch touchup of field-descs. (obsolete) — Splinter Review
Assignee: mattyt-bugzilla → administration
QA Contact: justdave → default-qa
Target Milestone: Bugzilla 2.22 → ---
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: administration → pdemarco
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 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 on attachment 233867 [details] [diff] [review]
new install defaults REMIND and LATER are removed.

You also have to fix contrib/ @ 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/ which doesn't use it.

Else your patch works fine. I just tested it on a fresh installation.
Attachment #233867 - Flags: review?(LpSolit) → review-
About contrib/, you should probably force it to make sure that LATER is a valid resolution, and if not, use another valid one.
changes made per communication on IRC
Attachment #233867 - Attachment is obsolete: true
Attachment #236598 - Flags: review?(LpSolit)
Comment on attachment 236598 [details] [diff] [review]
with some extra files changed

Attachment #236598 - Flags: review?(LpSolit) → review+
Flags: approval?
Flags: approval? → approval+
Checking in Bugzilla/;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/,v  <--
new revision: 1.85; previous revision: 1.84
Checking in contrib/;
/cvsroot/mozilla/webtools/bugzilla/contrib/,v  <--
new revision: 1.8; previous revision: 1.7
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
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
Closed: 13 years ago
Resolution: --- → FIXED
Keywords: relnote
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.