REMIND and LATER considered harmful.

RESOLVED FIXED in Bugzilla 3.0

Status

()

task
P3
normal
RESOLVED FIXED
20 years ago
12 years ago

People

(Reporter: CodeMachine, Assigned: pjdemarco)

Tracking

2.13
Bugzilla 3.0
Bug Flags:
approval +

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

20 years ago
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

20 years ago
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.

Comment 4

20 years ago
I think the mpt@mailandnews.com comment is orthogonal to this bug.

Updated

20 years ago
Status: NEW → ASSIGNED
Priority: P3 → P5

Comment 5

20 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

20 years ago
This is really a mozilla.org policy issue.  What is the proper forum for
resolving it?

Comment 7

20 years ago
You can try the netscape.public.mozilla.qa.general newsgroup.
(Reporter)

Comment 8

20 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

20 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

19 years ago
Every bug maybe, but what about enhancements?  There are lots in this system.
(Reporter)

Comment 11

19 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

19 years ago
Enhancements without assigned resources are now regularly left open and assigned 
to nobody@mozilla.org.
(Reporter)

Comment 13

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

19 years ago
Not suprisingly, I found someone the other day whose most popular votes query
didn't have REMIND and LATER.

Comment 16

19 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

19 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

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

19 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

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

Comment 22

19 years ago
definitely not for 2.12 at this point
Whiteboard: 2.12
(Reporter)

Comment 23

18 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
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 → --
(Reporter)

Comment 26

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

18 years ago
I am working on a solution for this by implementing customised resolutions over
at bug #94534.
(Reporter)

Comment 29

18 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

18 years ago
Depends on: bz-custres
(Reporter)

Comment 30

18 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)

Comment 31

18 years ago
Taking (again) ...
Assignee: justdave → matty
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

18 years ago
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

Comment 33

16 years ago
Are there any news regarding this bug? (Last comment is from November 2001)
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?
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

Comment 38

14 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

14 years ago
Posted 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.

Comment 40

14 years ago
Posted patch patch for localconfig (obsolete) — Splinter Review

Comment 41

14 years ago
Posted patch patch to checksetup (obsolete) — Splinter Review
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

14 years ago
Posted patch touchup of field-descs. (obsolete) — Splinter Review

Updated

14 years ago
Assignee: mattyt-bugzilla → administration
Status: ASSIGNED → NEW
QA Contact: justdave → default-qa
Target Milestone: Bugzilla 2.22 → ---

Comment 43

13 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)

Updated

13 years ago
Assignee: administration → pdemarco
(Assignee)

Comment 44

13 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?
(Assignee)

Updated

13 years ago
Attachment #233867 - Flags: review? → review?(mkanat)
(Assignee)

Updated

13 years ago
Attachment #233867 - Flags: review?(mkanat) → review?(LpSolit)

Comment 45

13 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

13 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

13 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

13 years ago
changes made per communication on IRC
Attachment #233867 - Attachment is obsolete: true
Attachment #236598 - Flags: review?(LpSolit)

Comment 49

13 years ago
Comment on attachment 236598 [details] [diff] [review]
with some extra files changed

r=LpSolit
Attachment #236598 - Flags: review?(LpSolit) → review+

Updated

13 years ago
Flags: approval?
Flags: approval? → approval+

Comment 50

13 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
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
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.