13534 - REMIND and LATER considered harmful.

Status: RESOLVED FIXED

(Bugzilla :: Administration, task, P3)

Description

[Matthew Tuck [:CodeMachine]]

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

Note that this works just as well for closed or in-house projects that use
Bugzilla.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Remind and later could just be added to the milestone list (and removed
elsewhere).  This seems like a good idea.

Comment 2

[Matthew Tuck [:CodeMachine]]

I think remind is unnecessary, and "No Target" is a better, although longer name
for "Later".

Comment 3

[Matthew T (active 1999-2002)]

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

[John G. Myers]

I think the [e-mail] comment is orthogonal to this bug.

Comment 5

[Terry Weissman]

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

[John G. Myers]

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

Comment 7

[Terry Weissman]

You can try the netscape.public.mozilla.qa.general newsgroup.

Comment 8

[Matthew Tuck [:CodeMachine]]

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

[John G. Myers]

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.

Comment 10

[Matthew Tuck [:CodeMachine]]

Every bug maybe, but what about enhancements?  There are lots in this system.

Comment 11

[Matthew Tuck [:CodeMachine]]

MPT, one problem with your proposal is that Closed loses the
Fixed/WontFix/Invalid/etc. resolution.  Have you filed this separately yet?

Comment 12

[John G. Myers]

Enhancements without assigned resources are now regularly left open and assigned 
to [e-mail].

Comment 13

[Matthew Tuck [:CodeMachine]]

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

[Matthew T (active 1999-2002)]

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

Comment 15

[Matthew Tuck [:CodeMachine]]

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

Comment 16

[Terry Weissman]

[e-mail] 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 .)

Comment 17

[Jesse Ruderman]

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.

Comment 18

[Matthew Tuck [:CodeMachine]]

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.

Comment 19

[Dave Miller [:justdave]]

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

[Jacob Steenhagen]

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.

Comment 21

[Matthew Tuck [:CodeMachine]]

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

[Tara Hernandez]

definitely not for 2.12 at this point

Comment 23

[Matthew Tuck [:CodeMachine]]

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.

Comment 24

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 25

[Hixie (not reading bugmail)]

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

Comment 26

[Matthew Tuck [:CodeMachine]]

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

[Dave Miller [:justdave]]

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.

Comment 28

[Matthew Tuck [:CodeMachine]]

I am working on a solution for this by implementing customised resolutions over
at bug #94534.

Comment 29

[Matthew Tuck [:CodeMachine]]

As such, taking this ...

Comment 30

[Matthew Tuck [:CodeMachine]]

Moving to new Bugzilla product ...

Comment 31

[Matthew Tuck [:CodeMachine]]

Taking (again) ...

Comment 32

[Dave Miller [:justdave]]

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.

Comment 33

[Andreas Kuckartz]

Are there any news regarding this bug? (Last comment is from November 2001)

Comment 34

[Dave Miller [:justdave]]

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

[Dave Miller [:justdave]]

Taking Jake's bugs...  his Army Reserve unit has been deployed.

Comment 36

[Dave Miller [: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)

Comment 37

[Dave Miller [:justdave]]

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.

Comment 38

[Luis Villa]

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

[Luis Villa]

Attachment: patch for docs

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

[Luis Villa]

Attachment: patch for localconfig

Comment 41

[Luis Villa]

Attachment: patch to checksetup

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

[Luis Villa]

Attachment: touchup of field-descs.

Comment 43

[Frédéric Buclin]

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.

Comment 44

[Paul]

Attachment: new install defaults REMIND and LATER are removed.

Comment 45

[Kevin Benton]

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.

Comment 46

[Frédéric Buclin]

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.

Comment 47

[Frédéric Buclin]

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.

Comment 48

[Paul]

Attachment: with some extra files changed

changes made per communication on IRC

Comment 49

[Frédéric Buclin]

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

r=LpSolit

Comment 50

[Frédéric Buclin]

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

Comment 51

[Max Kanat-Alexander]

Added to relnotes in bug 349423. Please let me know if I missed any critical information about this bug in the release notes.