231856 - Add new WORKSNOW resolution for bmo

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task, P4)

Description

[Brian 'netdragon' Bober]

I had a bug that was 4 years old and somewhere down the pipeline was fixed, but
we don't know how. This bug we had to mark WORKSFORME, but it seems that
WORKSFORME is not an accurate resolution for a 4 year old bug.

That's why I propose WORKSNOW.

Comment 1

[Dave Miller [:justdave]]

how about "FIXED"?  If you know it really was broken at one point in time, and
it works now, then it did get fixed at some point.  You just don't know who
fixed it or when.

Comment 2

[Brian 'netdragon' Bober]

FIXED is ambigious about bugs that are fixed elsewhere. Worksnow is more
specific. WORKSFORME is not accurate and can lead to false impressions about
certain bugs.

Example:

http://bugzilla.mozilla.org/show_bug.cgi?id=52063


> ------- Additional Comment #11 From Brian 'netdragon' Bober  2004-01-22 02:42
> -------
> 
> --> Fixed
> 
> This bug was obviously fixed somewhere down the road.
> 
> The testcase is still used by bug 57617, which still has not been fixed.
> 
> 
> ------- Additional Comment #12 From David Baron 2004-01-22 09:56 -------
> 
> Sorry, if we don't know what fixed a bug, it's WORKSFORME.  (We could have an
> additional WORKSNOW resolution, but we don't.)  We limit the use of FIXED to
> bugs where we know what fixed the bug.

Comment 3

[Matthew Tuck [:CodeMachine]]

Yes, FIXED makes 10 times more sense than WORKSFORME, but it would still be
useful for another resolution.  I was thinking DONE or something, WORKSNOW would
be better, except the first 4 letters of a resolution need to be unique, so
NOWWORKS might be a better option.

I will take a look at doing something like this when custom resolutions land, I
have already changed the default resolution set a bit to improve it, this could
be a nice addition.

Comment 4

[Jouni Heikniemi]

Although this doesn't have a lot to do with the specific subject here, we should
IMO be very cautious with identifiers whose names consist of several catenated
words. One of our coders, for example, used Bugzilla for several months before
he realized that "WORKSFORME" actually consists of three words "works for me".
Not being an native English speaker tends to make it difficult to figure the
word structure at a glance... Of course he would've figured it out with some
thought, but it didn't come naturally.

For an extremely short while, I actually thought we're talking about work-snow here.

Comment 5

[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 6

[Frédéric Buclin]

Why should this bug be different from bug 23531 which has been marked WONTFIX? I
suggest to mark it as a dupe of bug 94534.

Comment 7

[Brian 'netdragon' Bober]

This can be fixed without fixing bug 94534

Comment 8

[Jason Pyeron]

is this saying to add it to b.m.o or to the default installs?

anyone can add it to their site, RTFM
for b.m.o, just mark it FIXED and note with 

    "dont know how, why or when but it is"

Comment 9

[Stephen Lee]

Just a couple of thoughts:

- if all changes to the source code have a corresponding bug number, then 
anything that was broken but now started working must have been fixed by SOME 
code change (or combination of code changes) since the bug was observed...

... therefore a correct resolution would be resolved DUPLICATE of whatever bug 
provided the fix (or perhaps as depending on the bug that provided the fix, and 
then resolved FIXED with a comment like "fixed by blocker").

- it may not always be feasible to determine exactly which fix(es) did provided 
the fix to observed behaviour.


A possible solution would be to add a pseudo-bug for "The Unknown Fixed Bug", 
which could be marked as blocking bugs which seemed to fix themselves, or which 
they could be marked as duplicate of. If the real fix is later identified, then 
the association could then be moved to the appropriate bug report.

This could either be implemented with a "well-known" bug number, or with some 
magic UI options built into bugzilla.

Comment 10

[Frédéric Buclin]

(In reply to comment #7)
> This can be fixed without fixing bug 94534

Certainly, yes. But do we really want this? Resolving bug 94534 will also fix
this bug. I think WONTFIX for this bug would be nice (or marked as a dupe of bug
94534, as I said before).

Comment 11

[Brian 'netdragon' Bober]

Jason: <offtopic>Please don't implicitly say the F word on bugzilla.mozilla.org
or other insulting or aggressive statements. Please get RTFM out of your
vocabulary, along with all other disrespectful, insulting, or offensive
behavior. This isn't Freenode IRC or Usenet, and a certain level of
professionalism is expected.</offtopic>

This bug is saying to add it to the _default_ resolutions, along with perhaps
adding the resolution when they upgrade to tip. This isn't about b.m.o, but
wouldn't be bad to see. Since we have been discussing the need of this
resolution for almost 3 years. It is irrelevant whether someone can add it
manually if it's not there by default, which is what I am asking for.


Re comment #9 (Stephen): I thought about that, but you could have one bug fixed
by a totally irrelevant bug. Such as rewriting nsEventStateManager
unintentionally fixing some mouse events not getting serviced. Marking it
duplicate would be misleading. Especially since sometimes bugs that are closed
are still important for reference purposes.

> it may not always be feasible to determine exactly which fix(es) did provided
> the fix to observed behaviour.

I didn't think about that, but that's true also.

There is also the fact that WORKSFORME and DUPLICATE resolutions don't look good
for a bugzilla user (especially if they were a QA for a corporation and their
bug-finding performance were evaluated by looking at their list of bug reports).
It's not fair they get such a resolution if they actually submitted a valid bug
(and perhaps a rare INVALID in such cases of major code rewrites).

Fred: Customized resolutions would be nice, but this is a much more common case
than people realize. Probably 20,000 or more bugs in b.m.o fall under this
category, for instance. It'd be nice to be there by default.

Comment 12

[Frédéric Buclin]

(In reply to comment #11)
> This bug is saying to add it to the _default_ resolutions

I understood that! ;-) Now, I am thinking about MattyT's comment 3 about the
uniqueness of the 4 first letters and the conflict of WORKSNOW with WORKSFORME.
Personally, I would say that a bug marked WORKSFORME *is* INVALID, isn't it?
Both definitions are the same, IMHO. So my suggestion would be to replace
WORKSFORME by WORKSNOW (or any other term), which can technically easily be done
(simply replace one word by the other one in the full tree and edit
bug_status.html to insert the definition of this new resolution).

Another pertinent point, mentioned by Gerv in his blog, is about *old*
UNCONFIRMED bugs (let's say: more than a year) in which activity is low or
non-existent. Sometimes, the reporter made a poor description of the problem and
cannot be verified, or the URL where the problem should be is not valid anymore,
or the bug is not worth investigating to determine if it should be marked
WONTFIX or INVALID. For these bugs, a good resolution could be OLDBUG, DEADBUG,
OUTOFDATE, UNVERIFIED, UNTESTED or ZOMBIE.


> resolution for almost 3 years. It is irrelevant whether someone can add it
> manually if it's not there by default, which is what I am asking for.

Now, I understand your point of view!


> > it may not always be feasible to determine exactly which fix(es) did 
> > provided the fix to observed behaviour.

In this special case, WORKSNOW sounds good! ;-)


I do not think this bug will be solved as is. I discussed yesterday with
justdave on IRC and he told me customised resolutions was the way to go. So you
should keep the dependency with bug 94534 to be informed when this bug will be
resolved. And the guys there will notice your request more easily.

Comment 13

[Brian 'netdragon' Bober]

Since Dave said customized resolutions is the way to go, adding back dependency.
See also bug 136107 for a NEEDINFO status.

I'm not sure about getting rid of WORKSFORME. It's a tough call since WORKSFORME
bugs are not necessarily invalid, just hard to reproduce. WORKSFORME is a clunky
name, though. If not removed, maybe it could be changed to CANTCOMFIRM or something.

Comment 14

[Frédéric Buclin]

the trunk is frozen to prepare bugzilla 2.22

Comment 15

[Max Kanat-Alexander]

We won't be fixing this in upstream Bugzilla, because we won't be adding any new resolutions, now that there are custom resolutions.

However, perhaps once b.m.o upgrades to a version that allows custom resolutions, you could convince them to add this one.

Comment 16

[Gervase Markham [:gerv]]

There's diminishing returns in adding lots of different resolutions for finely-differentiated types of bug. How old does it have to be before you use WORKSNOW rather than WORKSFORME?

I suggest we WONTFIX this one. There are better suggestions for more resolutions.

Gerv

Comment 17

[Jesse Ruderman]

If this is wontfixed, bmo needs to either fix bug 385520 (update the description of WORKSFORME) or switch to using FIXED instead of WORKSFORME for this case.

Comment 18

[Jonathan Watt [:jwatt]]

From a reporter's point of view, using FIXED for bugs that have disappeared may make sense, but from a developers point of view it does not. I [would like to] only use FIXED for bugs where we know the checkin(s) that resolved the issue. Thus I think two different resolutions, WORKS_NOW and WORKSFORME/CANT_REPRODUCE, is useful. (I assume we can use underscores (or even spaces!) to make the resolutions more legible?)

Comment 19

[石庭豐 (Seak, Teng-Fong)]

According to others, it's important that the first four letters are different.  Using underscore doesn't seem to get into their definition. Well...

Comment 20

[Dave Miller [:justdave]]

Rearranging this component to not have me as the default assignee, so that it doesn't appear like I'm intending to work on bugs that other people could be taking care of if they didn't think I was already doing them.  If this bug is a software issue on b.m.o and you'd like to fix it, the modified source is now available for the patching (see bug 373688).  Reassigning to the new default owner.

Comment 21

[石庭豐 (Seak, Teng-Fong)]

Almost three years have passed.  Wondering if there's any decision on this enhancement.  Are we to use WORKSFORME in all its ambiguity knowing that it could be interpreted differently by different people?

Comment 22

[:glob ✱]

while this resolution may help clarify the true state of some bugs, we're putting a freeze on the current statuses and resolutions, due to the impact changing these will have on systems which integrate with bmo (such as dashboards).