New "INCOMPLETE" resolution in Bugzilla

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Wayne Mery
On 4/9/2007 6:42 PM, Tony Mechelynck wrote:

> Gervase Markham wrote:
>> Gervase Markham wrote:
>>> To add more data to the discussion, I went through 26 other Bugzillas
>>> from the biggest free software projects (as listed on
>>> http://www.bugzilla.org/installation-list/) to see what they do. The
>>> results are very interesting.
>>
>> And now some personal views on what it means.
>>
>> Everyone else seems to have plumped for NEEDINFO rather than READY as
>> the extra state before the bug is assigned to be fixed. So there is an
>> argument from consistency about us adopting it. I note mconnor's
>> suggestion that we need both; but I'm not sure we really do (see my
>> reply to his message). The Bugzilla team should consider adding this
>> status as a core feature.
>>
>> Another option would be to make it possible to push a bug back into
>> UNCONFIRMED; then UNCONFIRMED would work like NEEDINFO - i.e. "we
>> don't know if this bug is good yet". That might achieve the same end
>> with less disruption.
>
> IIUC, there is a problem with triage: every bug starts it life as
> UNCONFIRMED, so an UNCONFIRMED bug typically draws the triagers'
> attention. If the bug is reproducible it becomes NEW, if it's not a bug
> it becomes RESOLVED INVALID, if that bug has already been sighted it
> becomes RESOLVED DUPLICATE, etc. But how can a triager mark a bug to
> mean "I can't move this bug because the report isn't complete"? NEEDINFO
> would allow him to mark the bug so that he (or his colleagues) wouldn't
> need to waste time perpetually going back to this bug, only to see it
> isn't in a "triageable" state.

Strongly agree that using UNCONFIRMED as a synonym to "needs
information" is not a good option.

Searching with "ever confirmed" might partly address the triage concern.
  But it would make triage of more difficult. And it's hard enough (i.e.
impossible) to select on bugs that have never been touched, eg. has no
comments other than the original report.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
Wayne Mery wrote:
> Strongly agree that using UNCONFIRMED as a synonym to "needs
> information" is not a good option.

OK, scratch that idea.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
In reply to this post by Gervase Markham
Gervase Markham wrote:

> Gervase Markham wrote:
>> To add more data to the discussion, I went through 26 other Bugzillas
>> from the biggest free software projects (as listed on
>> http://www.bugzilla.org/installation-list/) to see what they do. The
>> results are very interesting.
>
> And now some personal views on what it means.
>
> Everyone else seems to have plumped for NEEDINFO rather than READY as
> the extra state before the bug is assigned to be fixed. So there is an
> argument from consistency about us adopting it. I note mconnor's
> suggestion that we need both; but I'm not sure we really do (see my
> reply to his message). The Bugzilla team should consider adding this
> status as a core feature.
>
> Another option would be to make it possible to push a bug back into
> UNCONFIRMED; then UNCONFIRMED would work like NEEDINFO - i.e. "we don't
> know if this bug is good yet". That might achieve the same end with less
> disruption.
>
> In terms of the resolution question, if we are going to go with
> something like INCOMPLETE, we could either match the Linux kernel and
> Red Hat with INSUFFICIENT_DATA (or INSUFFICIENTDATA to match WORKSFORME
> etc.) or match only GNOME with INCOMPLETE.
>
> I'd be interested to know how those other projects deal with the class
> of bugs we are discussing. Do they just use INVALID or WORKSFORME and
> lump it?

Trying to figure out the context since it's not entirely clear from this
post.  Assuming you're meaning "bugs that once existed but have since
been fixed and nobody knows what fixed it?"

We try to avoid marking bugs WORKSFORME.  Clearly the bug was seen at
least once for the reporter to file a bug so it's rather unfair to mark WFM.

We use CURRENTRELEASE, NEXTRELEASE or RAWHIDE depending on where the bug
was filed and where it was fixed.  For example, bugs filed against FC6
that get an update issued against FC6 which now resolves the issue get
CURRENTRELEASE.  If it's not going to be fixed in FC6 but will be in
FC7, it gets NEXTRELEASE.  If the bug was filed against a non-release
(rawhide) we'll simply mark it RAWHIDE when it's fixed if we don't know
where.

We follow this pretty well for RHEL bugs (although we also avoid
resolving things as rawhide for RHEL bugs), but Fedora, much like other
projects, encourages people to contribute by using the latest for
testing and development, so in practice most bugs are tested only on
rawhide and thus the RAWHIDE resolution is rather abused for Fedora bugs.

https://bugzilla.redhat.com/bugzilla/page.cgi?id=fields.html#resolution
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Christopher Aillon wrote:
> We try to avoid marking bugs WORKSFORME.  Clearly the bug was seen at
> least once for the reporter to file a bug so it's rather unfair to mark
> WFM.

Why so? The "FORME" part means it works for you; it doesn't tell them
that they were hallucinating.

> We use CURRENTRELEASE, NEXTRELEASE or RAWHIDE depending on where the bug
> was filed and where it was fixed.  For example, bugs filed against FC6
> that get an update issued against FC6 which now resolves the issue get
> CURRENTRELEASE.

...which goes out of date when FC6 is no longer the current release?

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
Gervase Markham wrote:
> Christopher Aillon wrote:
>> We try to avoid marking bugs WORKSFORME.  Clearly the bug was seen at
>> least once for the reporter to file a bug so it's rather unfair to mark
>> WFM.
>
> Why so? The "FORME" part means it works for you; it doesn't tell them
> that they were hallucinating.

No, they weren't hallucinating, but clearly nobody cares enough to leave
it open.  The reporter shouldn't care _who_ it works for until it works
for _them_.  It's great if it works for someone else, but _I_ filed the
bug and _I_ want it fixed.


>> We use CURRENTRELEASE, NEXTRELEASE or RAWHIDE depending on where the bug
>> was filed and where it was fixed.  For example, bugs filed against FC6
>> that get an update issued against FC6 which now resolves the issue get
>> CURRENTRELEASE.
>
> ...which goes out of date when FC6 is no longer the current release?

I never said I liked the naming, but those also have a text field
attached to them where we input precisely which release it is fixed in.
  Some of those resolutions can't be used without filling in the text field.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Gervase Markham wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=369544
>
> In a few days, we plan to create a new "INCOMPLETE" resolution in
> Bugzilla, taking advantage of the new "custom resolutions" feature.

I've just been back through the discussion; it seems that people are OK
with the principle but there is some disagreement on the name.

- majken and stephanie are happy with INCOMPLETE, which matches GNOME.

- caillon suggested INSUFFICIENT_DATA, which matches RedHat and the
kernel; shaver also liked this.

- shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
but either might be confused with a forthcoming NEEDINFO status.

** I suggest we choose between INCOMPLETE and INSUFFICIENT_DATA. I'm
happy with either. I don't really want to have a vote, though, because
it implies everyone's opinion carries equal weight. Thoughts? **

There's also some support for a NOTABUG/NOTMOZILLA/CANTFIX-style resolution.

I should also note that I've been working with Bugzilla developer
LpSolit to implement custom statuses for Bugzilla, which would allow us
to add the NEEDINFO and READY states if we wanted them. Let's not count
our chickens, but we hope to have this work finished in a few weeks.
Then, of course, b.m.o. would need to be upgraded.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
Most of the time that's how worksforme is used, the reporter says it
works, or if something gets fixed, but people don't want to go through
figuring out which check-in did it.  I think the only cases where
something is marked worskforme without the reporter is if someone asks
the reporter to report back and they don't.  In any case, most of
those in the grey area would now fall under incomplete (or whatever it
actually gets called).

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Adam Kowalczyk
In reply to this post by Gervase Markham
Gervase Markham wrote:
> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
> but either might be confused with a forthcoming NEEDINFO status.

To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

I also think it better reflects the meaning we're trying to convey,
because it doesn't suggest that more information is needed (as in
"desired") in such bug. To my understanding, we don't expect to receive
any more information in this bug, because if we did then we would have
left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

- Adam
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Adam Kowalczyk
In reply to this post by Gervase Markham
Gervase Markham wrote:
> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
> but either might be confused with a forthcoming NEEDINFO status.

To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

I also think it better reflects the meaning we're trying to convey,
because it doesn't suggest that more information is needed (as in
"desired") in such bug. To my understanding, we don't expect to receive
any more information in this bug, because if we did then we would have
left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

- Adam
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Adam Kowalczyk
In reply to this post by Gervase Markham
Gervase Markham wrote:
> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
> but either might be confused with a forthcoming NEEDINFO status.

To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

I also think it better reflects the meaning we're trying to convey,
because it doesn't suggest that more information is needed (as in
"desired") in such bug. To my understanding, we don't expect to receive
any more information in this bug, because if we did then we would have
left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

- Adam
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Adam Kowalczyk
In reply to this post by Gervase Markham
Gervase Markham wrote:
> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
> but either might be confused with a forthcoming NEEDINFO status.

To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

I also think it better reflects the meaning we're trying to convey,
because it doesn't suggest that more information is needed (as in
"desired") in such bug. To my understanding, we don't expect to receive
any more information in this bug, because if we did then we would have
left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

- Adam
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Adam Kowalczyk
In reply to this post by Gervase Markham
Gervase Markham wrote:
> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
> but either might be confused with a forthcoming NEEDINFO status.

To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

I also think it better reflects the meaning we're trying to convey,
because it doesn't suggest that more information is needed (as in
"desired") in such bug. To my understanding, we don't expect to receive
any more information in this bug, because if we did then we would have
left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

- Adam
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Michael Lefevre
In reply to this post by Adam Kowalczyk
On 2007-04-18, Adam Kowalczyk <[hidden email]> wrote:

> Gervase Markham wrote:
>> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
>> but either might be confused with a forthcoming NEEDINFO status.
>
> To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.
>
> I also think it better reflects the meaning we're trying to convey,
> because it doesn't suggest that more information is needed (as in
> "desired") in such bug. To my understanding, we don't expect to receive
> any more information in this bug, because if we did then we would have
> left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.

I think you're right. However, I think shaver was proposing a different
usage, in which we would be hoping that people would provide additional
information in the same bug and reopen it. If that is the case, then his
suggested name is good. If the procedure is going to be that poor reports
are resolved immediately with this new resolution and reporters encouraged
to file new bugs, then a more final sounding resolution (e.g. INCOMPLETE)
would be better, IMHO.

--
Michael
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Tony Mechelynck
Michael Lefevre wrote:

> On 2007-04-18, Adam Kowalczyk <[hidden email]> wrote:
>> Gervase Markham wrote:
>>> - shaver suggested NEEDS_INFORMATION (possibly shortenable to NEEDSINFO)
>>> but either might be confused with a forthcoming NEEDINFO status.
>> To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.
>>
>> I also think it better reflects the meaning we're trying to convey,
>> because it doesn't suggest that more information is needed (as in
>> "desired") in such bug. To my understanding, we don't expect to receive
>> any more information in this bug, because if we did then we would have
>> left it in NEEDSINFO status instead of resolving it. But maybe I'm wrong.
>
> I think you're right. However, I think shaver was proposing a different
> usage, in which we would be hoping that people would provide additional
> information in the same bug and reopen it. If that is the case, then his
> suggested name is good. If the procedure is going to be that poor reports
> are resolved immediately with this new resolution and reporters encouraged
> to file new bugs, then a more final sounding resolution (e.g. INCOMPLETE)
> would be better, IMHO.
>

There was a movement of opinion in favour of both a new status (such as
NEED(S)INFO) for bugs which have newly appeared but cannot be reproduced
because the report is incomplete (but devs still hope the reporter will
someday soon provide the missing info), and a new resolution (for instance,
RESOLVED LACKSINFO) for bugs where it is expected that the missing information
will never be forthcoming. It was my understanding that NEEDSINFO might evolve
to RESOLVED LACKSINFO but only after a "reasonable" length of time had
elapsed. These might, of course, still be REOPENED if the missing info does
come forth after all.

Currently, the former kind of bugs are left as UNCONFIRMED, which creates a
triage problem, and the latter are RESOLVED INVALID, which may be seen by some
as offensive to the reporter, and creates a confusion with the "it's not a
bug, it's a feature" kind of resolution.


Best regards,
Tony.
--
Give me the Luxuries, and the Hell with the Necessities!
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Michael Lefevre
On 2007-04-18, Tony Mechelynck <[hidden email]> wrote:
[snip]
>
> There was a movement of opinion in favour of both a new status (such as
> NEED(S)INFO) for bugs which have newly appeared but cannot be reproduced
> because the report is incomplete (but devs still hope the reporter will
> someday soon provide the missing info), and a new resolution (for instance,
[snip]

I'm afraid I'm confusing things further by following up in this thread
rather than the newer thread which is in m.d.general.

There was that movement of opinion, however, as I understand it, the
resolution should be a reality in a matter of days, while the status is
something for the longer term (because it's not easy to make that addition
to b.m.o).  Therefore I think the name for the resolution should reflect
how it's going to be used at the moment, rather than being based on a
future change that hasn't been decided (or has it?) and won't be
implemented for a while even when it is.

--
Michael
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
Michael Lefevre wrote:
> I'm afraid I'm confusing things further by following up in this thread
> rather than the newer thread which is in m.d.general.

Ignore m.d.general. Pretend it doesn't exist.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Adam Kowalczyk
Adam Kowalczyk wrote:
> To avoid the confusion we can call it LACKS_INFORMATION/LACKSINFO.

Guys, we're starting to dance on the head of a pin here. We now have
three options - INCOMPLETE, INSUFFICIENT_DATA and LACKSINFO - and they
all mean basically the same thing! If some consensus doesn't emerge I'm
just going to put my foot down and pick one.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Michael Lefevre
In reply to this post by Gervase Markham
[crossposted back to mozilla.dev.planning and followups set]

On 2007-04-20, Gervase Markham <[hidden email]> wrote:

> Michael Lefevre wrote:
>> On 2007-04-18, Gervase Markham <[hidden email]> wrote:
>>> AC wrote:
>> [...]
>>>> RESOLVED: INSUFFICIENT_DATA, is partly better, because it uses the
>>>> concept of 'sufficient' (to reproduce the problem) rather than
>>>> 'complete'.  But since it contains the word 'sufficient', there is still
>>>> possible confusion that it is like NEEDINFO and can be continued with
>>>> more data.
>>> Er... it can.
>>
>> Can it?  My understanding was that the current suggestion was that
>> incomplete/insufficient reports would be resolved quickly with this
>> resolution, and reporters encouraged to file new bug reports (in the hopes
>> that they'd make a better job of it next time).
>
> My point was merely that any bug can be reopened.

Well I know that's technically true, of course.

If the policy is going to be that bad bug reports are closed and reporters
are told to file new bugs, then the resolution should not suggest that a
bug report could be reopened (and people shouldn't be making the point
that bugs can be reopened!).

Actually I don't think that closing incomplete bugs and filing new ones is
the best idea, but if that's going to be the policy, then as far as
possible everyone should stick to it - we shouldn't have QA people doing
one thing and telling reporters that that is the way it should be done,
and then some developers doing something completely different.

--
Michael
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Andrew Schultz-2
Michael Lefevre wrote:
> If the policy is going to be that bad bug reports are closed and reporters
> are told to file new bugs, then the resolution should not suggest that a
> bug report could be reopened (and people shouldn't be making the point
> that bugs can be reopened!).

I don't think anyone has spoken in favor of this except for mconnor.  It
seems bad as a blanket policy.  Filing is probably better if there is
absolutely no useful info in the original bug.  I'd assert that in most
of those cases, the bug is generally bogus (even with more info) and
shouldn't be refiled anyway.

If the objective here is to add a resolution that's less inflammatory
than INVALID, then forcing people to re-file is an excellent way to be
much more inflammatory.

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Andrew Schultz-2
Andrew Schultz wrote:
> I don't think anyone has spoken in favor of this except for mconnor.  It
> seems bad as a blanket policy.  Filing is probably better if there is
> absolutely no useful info in the original bug.  I'd assert that in most
> of those cases, the bug is generally bogus (even with more info) and
> shouldn't be refiled anyway.

... and perhaps more importantly, most bugs do have some useful info.

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345