New "INCOMPLETE" resolution in Bugzilla
Gervase Markham
In a few days, we plan to create a new "INCOMPLETE" resolution in
Bugzilla, taking advantage of the new "custom resolutions" feature.
This is basically for resolving bugs which have insufficient information
in them. Up to now, INVALID has been used, but semantically that's not
quite right, and it is a bit rude.
The name matches a resolution GNOME are already using; consistency is nice.
Gerv
Christopher Aillon
FWIW, Red Hat uses INSUFFICIENT_DATA, which is more accurate and IMO,
less ambiguous. What's incomplete? The bug report? The work on fixing
the bug?
Mike Shaver
> less ambiguous. What's incomplete? The bug report? The work on fixing
> the bug?
I agree, that would be clearer. "NEEDS INFORMATION" might be clearer still?
Mike
Christopher Aillon
We also have a NEEDINFO state for currently open bugs. It's a
flag-based state where someone can request info from a given user, e.g.
the reporter, or a module owner, et al. Typically a bug goes to
NEEDINFO first to request the information be provided, and after a
reasonable time has passed, it gets resolved INSUFFICIENT_DATA.
maj...@gmail.com
think the idea with any bug being resolved INCOMPLETE is that the
person marking it so would also give a brief explanation why, and
almost always directing the reporter to support avenues to help find
the complete information and refile. The other problem with NEEDS
INFORMATION is that it implies that more information is desired, which
we want to avoid.
A quick thesaurus search though, isn't providing any better examples
that are short, with the exception of "gremlins" everything short is
pretty insulting.
I personally think the context and the users would make INCOMPLETE
make sense (especially in combination with resolved), but respect the
argument that something more descriptive might be necessary. I'm not
sure how to get around that though without saying ____ REPORT.
Dan Mosedale
> The other problem with NEEDS INFORMATION is that it implies that more
> information is desired, which we want to avoid.
Why do we want to avoid that? Isn't that, in fact, exactly what we
want to express?
Dan
Mike Connor
This is unclearly stated, but my thinking is that we want to avoid
reopening that particular bug, instead encouraging the reporter to
file a clean and detailed report.
-- Mike
Gervase Markham
> We also have a NEEDINFO state for currently open bugs.
Sadly, the particular design and customisation capabilities of Bugzilla
mean that adding a new resolution is easy, whereas adding a new status
is hard. Ideally, technology wouldn't dictate policy, but that's just
the way it is.
Adding a new resolution is easy, and it's still taken us six months.
Gerv
Mike Shaver
>
> On 27-Mar-07, at 3:53 PM, Dan Mosedale wrote:
>
> reopening that particular bug, instead encouraging the reporter to
> file a clean and detailed report.
If the bug is a bad report, maybe, but telling them that they should
file a new bug because we want them to tell us more about which
version of something they're using, or if they have a given extension
installed, etc. seems like the wrong path. We lose all the cc: state
and such when the reporter does that, so I think we should generally
avoid it unless the bug is so messed up as to be a significant
impediment to actually fixing it.
Mike
Stephanie
A NEEDINFO state is needed much more than a missing info resolution
though. FWIW, a missing info resolution's more a technicality. Once a
bug's appropriately resolved, it tends to stay that way. Tracking what
bugs require action from the reporter (and being able to query or
filter by that) is of critical importance to efficient handling of
bugs, particularly unconfirmed bugs where we have to prod the reporter
for enough details to reproduce.
Given that this has been implemented by several downstream users of
Bugzilla, I still don't see what the difficulty is in having this, but
it's been held off since 2002 for a "perfect" solution, when at this
point, almost any solution would be an improvement, at least as far as
bugzilla.mozilla.org goes.
We have tremendous duplication of effort for the triagers dealing with
unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
bugs have to be examined repeatedly only to see that they are waiting
for a reply. This takes time up that could be used confirming bugs for
which there's actually enough information to work with, and
contributes greatly to the frustration of anyone working with
unconfirmed bugs.
--Stephanie
maj...@gmail.com
that's the stats on how often a "my bookmarks are broken" bug actually
gets the necessary info added, and how useful bugs are that don't have
clear str until comment #8. This is mconnor's area, though so if there
are questions about that, ask him!
Shaver - you're right, and I don't think any of the examples you gave
were intended to be marked INCOMPLETE although definitely fit in the
description of the word. I think for the most part any bugs that would
really get the resolution we're trying to decide on would be support
requests, or people filing a bug that should be seeking support
instead, i.e. something broke and so they're filing, and they've done
nothing to try and reproduce or look to see if there's an answer
somewhere.
This in some ways presents a grey area for valid issues that don't
have steps to reproduce. Part of what I really liked about the idea
of marking these bugs separately is the idea that they're still there,
and once steps to reproduce are found, those incomplete bugs (if it's
clear they're the same issue) can be duped forward. If it's not clear
enough, it still gives people a place to track these sorts of issues,
to piece things together, rather than having to sort through what's
invalid because it didn't make sense and what's invalid because it
really isn't a bug or leaving them unconfirmed. I think we don't want
20 people all saying "I'm having the same issue" in one bug before
it's found that it's actually 3 different issues. That usually gets
messy (ala copy/paste or bookmarks issues).
The only issue I see this raising is how to get people who are cc'ed
to the INCOMPLETE bug aware of the new properly filed bugs to try out
the STR . I think this can be overcome either by using META bugs to
organize the incomplete bugs by symptom, if the priority is getting
all reporters onto a valid bug (how many care, how many leave after
filing?), or by searching incomplete bugs for similar symptoms and
asking the reporters to check out the new bug if we need confirmation
on the STR (if we're pointing these people to support avenues anyway,
they can stay in touch with those avenues to check up on new bugs.
Even with the current system there's no guarrantee their bug will be
the one that gets the work in it or that their bug will be duped to
the right one.)
-Majken "Lucy" Connor
maj...@gmail.com
>
> We have tremendous duplication of effort for the triagers dealing with
> unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
> bugs have to be examined repeatedly only to see that they are waiting
> for a reply. This takes time up that could be used confirming bugs for
> which there's actually enough information to work with, and
> contributes greatly to the frustration of anyone working with
> unconfirmed bugs.
>
> --Stephanie
Stephanie - I might not be catching on to what you're meaning, but how
I'm understanding it, I don't see how it makes any difference to how
things are now. I'm not sure why the bugs have to be examined
repeatedly, and so maybe this is the heart of why I'm not getting it.
Even so, how would NEEDINFO change that? The way I'm grasping it,
you're watching the bug for more information either way.
The missing info state would mean you do one pass on the bug, see that
you can't simply ask a question like "do you have extensions
installed?" or "what version are you using?" Mark the bug as
INCOMPLETE (ideally this adds a canned response directing the reporter
to seek support who can either help solve their issue, or help them
troubleshoot the issue so they can file a complete bug) and then move
on.
Vladimir Vukicevic
> Given that this has been implemented by several downstream users of
> Bugzilla, I still don't see what the difficulty is in having this, but
> it's been held off since 2002 for a "perfect" solution, when at this
> point, almost any solution would be an improvement, at least as far as
> bugzilla.mozilla.org goes.
>
> We have tremendous duplication of effort for the triagers dealing with
> unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
> bugs have to be examined repeatedly only to see that they are waiting
> for a reply. This takes time up that could be used confirming bugs for
> which there's actually enough information to work with, and
> contributes greatly to the frustration of anyone working with
> unconfirmed bugs.
I very much agree here -- I think that the way the Red Hat bugzilla
works is exactly the functionality that we want here: a bug in the
NEEDINFO state reverts to NEW as soon as a comment is added, without the
commenter explicitly needing to set anything. If the commenter wants it
to stay in NEEDINFO, they explicitly have to set the state to NEEDINFO
when they submit their comment.
- Vlad
maj...@gmail.com
>
> I very much agree here -- I think that the way the Red Hat bugzilla
> works is exactly the functionality that we want here: a bug in the
> NEEDINFO state reverts to NEW as soon as a comment is added, without the
> commenter explicitly needing to set anything. If the commenter wants it
> to stay in NEEDINFO, they explicitly have to set the state to NEEDINFO
> when they submit their comment.
>
> - Vlad
So is this a case where the bug is confirmed but you need to find out
things like a regression window? If so, then that's a bit of a
different beast and I would want to avoid letting discussion on it
delay action on this, which deals with unconfirmed bugs.
Gervase Markham
> I very much agree here -- I think that the way the Red Hat bugzilla
> works is exactly the functionality that we want here: a bug in the
> NEEDINFO state reverts to NEW as soon as a comment is added, without the
> commenter explicitly needing to set anything.
If people are interested in making it easier to have b.m.o. take
functional enhancements of this sort, they need to be aware of how
things work at the moment.
As I understand it, the current way that b.m.o. is maintained is via a
single large patch on top of a particular release of Bugzilla. This
large patch can be obtained on request. It contains all sorts of
different changes, all mixed together.
I'm sure there are several people who would be happy to write custom
improvements for b.m.o. (I certainly include myself in this), but the
above arrangements make it more difficult than it needs to be to obtain
a copy of the current production code which you know is absolutely
correct, write and test a patch against it, and share the results of
that with other people for further testing.
It also seems very difficult to get patches that have been written
applied. I've been waiting for 18 months to get a patch I wrote at
mconnor's request applied:
https://bugzilla.mozilla.org/show_bug.cgi?id=314056
If the code running on b.m.o. were a branch in an SCM instead of a big
tarball patch, people could check it out, get it working for them, write
patches and test them with much greater ease. It would also make it much
easier for b.m.o. to be upgraded (and downgraded again if necessary) to
take safe incremental improvements - because there would not be manual
patching and merging steps involved.
(This is not an attempt to attack anyone; I'm just outlining the facts
as I understand them, and suggesting why we might have the problem we have.)
Gerv
Gervase Markham
> As I understand it, the current way that b.m.o. is maintained is via a
> single large patch on top of a particular release of Bugzilla. This
> large patch can be obtained on request. It contains all sorts of
> different changes, all mixed together.
My apologies; this is incorrect. There are multiple, distinct patches,
and they can be obtained as a .tar.gz (or .bz2; I forget) - which is why
I originally remembered there being just one file.
Of course, while this is better patch management, it doesn't make it any
easier to create your own version of the b.m.o. code.
Gerv
Peter Weilbacher
> I think an important point in this discussion is in the bug, and
> that's the stats on how often a "my bookmarks are broken" bug actually
> gets the necessary info added, and how useful bugs are that don't have
> clear str until comment #8.
What's "str" (or "STR" as you use it further down in your post)? If it's
more frequently used, perhaps you can add a definition to the glossary on
MDC?
Peter.
Peter Weilbacher
Apart from that it would also make it more difficult to find the right bug
in a Bugzilla search. It's already difficult enough now, even for people
who search for bugs on a daily basis.
Peter.
Gijs Kruitbosch
Steps to reproduce. I added a Glossary entry.
~ Gijs
Gervase Markham
> My apologies; this is incorrect.
Double apologies; I was right the first time! The huge patch can be
obtained from here:
http://landfill.bugzilla.org/prodpatches/huge-bmo-patch8.diff
Gerv
Gervase Markham
> If the code running on b.m.o. were a branch in an SCM instead of a big
> tarball patch, people could check it out, get it working for them, write
> patches and test them with much greater ease. It would also make it much
> easier for b.m.o. to be upgraded (and downgraded again if necessary) to
> take safe incremental improvements - because there would not be manual
> patching and merging steps involved.
preed (who is responsible for maintaining the b.m.o. codebase) tells me
that there are no plans for this to happen until a better SCM than CVS
comes along in which to put the code. If there was a b.m.o. branch, he
would want to restrict checkins to it, and CVS doesn't allow that.
Gerv
Gervase Markham
> If the code running on b.m.o. were a branch in an SCM instead of a big
> tarball patch, people could check it out, get it working for them, write
> patches and test them with much greater ease. It would also make it much
> easier for b.m.o. to be upgraded (and downgraded again if necessary) to
> take safe incremental improvements - because there would not be manual
> patching and merging steps involved.
Reed Loden (who is responsible for maintaining the b.m.o. codebase)
Christopher Aillon
> Vladimir Vukicevic wrote:
>> I very much agree here -- I think that the way the Red Hat bugzilla
>> works is exactly the functionality that we want here: a bug in the
>> NEEDINFO state reverts to NEW as soon as a comment is added, without the
>> commenter explicitly needing to set anything.
>
> If people are interested in making it easier to have b.m.o. take
> functional enhancements of this sort, they need to be aware of how
> things work at the moment.
I just talked to dkl who maintains our bugzilla. Sadly he doesn't have
a patch that is upstreamable right now because of some dependencies on
RH-bugzilla-specific stuff. We're going to port to bugzilla 3.0 though
in the near future and this will need to happen. Expect a patch in the
next two months for NEEDINFO support which can be submitted to both
upstream bugzilla and it could probably be used in ours as well,
hopefully with minimal merge conflicts (I've not seen either patchsets).
Mike Connor
On 27-Mar-07, at 7:51 PM, Mike Shaver wrote:
> On 3/27/07, Mike Connor <mco...@mozilla.com> wrote:
>>
>> On 27-Mar-07, at 3:53 PM, Dan Mosedale wrote:
>>
>> This is unclearly stated, but my thinking is that we want to avoid
>> reopening that particular bug, instead encouraging the reporter to
>> file a clean and detailed report.
>
> If the bug is a bad report, maybe, but telling them that they should
> file a new bug because we want them to tell us more about which
> version of something they're using, or if they have a given extension
> installed, etc. seems like the wrong path. We lose all the cc: state
> and such when the reporter does that, so I think we should generally
> avoid it unless the bug is so messed up as to be a significant
> impediment to actually fixing it.
I think that there are many bugs that are filed in such a state that
they're unfixable. The amount of time and comments it takes to get
to a useful bug report is inversely proportional to the odds it will
get fixed, which is why I have argued that such a bug is typically
not worth significant effort. NEEDINFO is an added intermediate step
for the grey areas, I would argue that bugs needing more info that
don't get another comment after a given time should automatically
change to INCOMPLETE in time. If we need more info from the
reporter, and we don't get that info in a reasonable amount of time,
the odds are slim at best that we'll ever get the needed information.
In terms of what we've been doing with triage in the last 3-4 years,
the guideline has been to resolve as INVALID or WORKSFORME anything
that is lacking the info needed to fix it, rather than commenting and
leaving as UNCONFIRMED, based on the low (< 3-4%) rate of responses
to triager questions. This is just adding another potential state
that is less inflammatory and more correct (INVALID is overloaded, as
we use it for both "this is not a bug, this is expected behaviour"
and "this bug lacks the required information.")
So NEEDINFO -> INCOMPLETE for the grey areas, and INCOMPLETE for
obviously poor bugs, with links to the right ways to follow up on
their issue.
-- Mike
Gervase Markham
> I think that there are many bugs that are filed in such a state that
> they're unfixable. The amount of time and comments it takes to get to a
> useful bug report is inversely proportional to the odds it will get
> fixed, which is why I have argued that such a bug is typically not worth
> significant effort.
Mike makes an important point. We need to accept at this stage that we
do not have the resources to exhaustively investigate every bug report
or complaint we get. (That's one reason Hendrix exists.) Therefore, we
should focus on those which are well-reported - because they give the
most bang for the buck.
If there's a problem affecting multiple people, there will be good and
bad bug reports of the same issue. As long as one of the good ones gets
dealt with, then we are OK. Recognising and closing out the bad ones
quickly is just good use of scarce resources.
Gerv
Gervase Markham
> I just talked to dkl who maintains our bugzilla. Sadly he doesn't have
> a patch that is upstreamable right now because of some dependencies on
> RH-bugzilla-specific stuff. We're going to port to bugzilla 3.0 though
> in the near future and this will need to happen. Expect a patch in the
> next two months for NEEDINFO support which can be submitted to both
> upstream bugzilla and it could probably be used in ours as well,
> hopefully with minimal merge conflicts (I've not seen either patchsets).
I would point out that the last time we discussed the Bugzilla workflow,
the agreed "ideal workflow" didn't include a NEEDINFO state. Instead, it
had a READY state.
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
Gerv
Stephanie Daugherty
Not really. Putting the bugs in NEEDINFO gets them out of UNCONFIRMED or
NEW, therefore making everything in the UNCONFIRMED state ready for some
form of triage - it will either go from UNCONFIRMED to NEW or from
UNCONFIRMED to NEEDINFO, or from UNCONFIRMED to RESOLVED.
There'd no longer be a wait in UNCONFIRMED for the reporter to reply to
comments - basically just making sure that the workflow clearly
indicates who needs to move the bug forward, instead of just a
UNCONFIRMED busy loop for the triagers of seeing the same bugs over and
over again until we realize they are old enough without further comment
to just RESOLVED INVALID.
Stephanie Daugherty
>
> I would point out that the last time we discussed the Bugzilla workflow,
> the agreed "ideal workflow" didn't include a NEEDINFO state. Instead, it
> had a READY state.
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>
> Gerv
Then either theres a need to change the guide for triagers and the
bugzilla process to say that it's ok to ruthlessly close bugs without
enough info on sight (ie, such bugs go directly to RESOLVED INCOMPLETE
right away, without trying to prod the reporter), or the "ideal"
workflow needs to better reflect the realities of bugs being filed
without enough information, and how we go about getting enough information.
Regardless, if bugs are sitting in UNCONFIRMED, we need somewhere to
send them as they are triaged, rather than have them sit there waiting
for enough information to trickle in to confirm them.
There's a major problem to be solved though, and the unconfirmed bug
lists aren't getting any smaller :(
--Stephanie
Andrew Schultz
That workflow may be ideal, but it makes quite a few assumptions that
are unrealistic
1. A bug that was once considered NEW will not end up WORKSFORME (this
happens all the time).
2. A bug that was once considered READY will not end up a DUPLICATE,
INVALID, WONTFIX or WORKSFORME.
In reality bugs that seem valid have to be re-evaluated occasionally,
mostly to catch the ones that have become WORSFORME and DUPLICATE due to
being fixed elsewhere.
We have a clean-report keyword in b.m.o that basically mimics the READY
status. benc pushed for it a long time ago and nobody uses it (except
him while he was still active).
Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
except that NEEDINFO more precisely describes the status of many bugs
that are waiting on feedback from someone specifically (usually the
reporter).
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Stephanie Daugherty
Hash: SHA1
Andrew Schultz wrote:
> Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
> except that NEEDINFO more precisely describes the status of many bugs
> that are waiting on feedback from someone specifically (usually the
> reporter).
>
I see NEEDINFO more useful to UNCONFIRMED than it is to NEW, although, I
would expect that a transition from NEW to NEEDINFO and back wouldn't be
all that uncommon either.
Really, the only big difference is that we'd basically be able to ignore
bugs while we're waiting for feedback from the reporter, and
periodically clean those bugs out by querying for NEEDINFO bugs that
haven't been changed in a long time.
Most importantly, as I said in another branch off this thread, this
would eliminate the need to periodically poll UNCONFIRMED bugs to see if
they are ready to be sent elsewhere, and would provide triagers a place
to send every unconfirmed bug - they would all be able to be confirmed,
needinfo, or resolved from the unconfirmed state, so we only need to
look at them once for each time they enter UNCONFIRMED.
- --Stephanie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGC9k6sUIV80N+s8sRAu2bAKCe7zZkQmsthZrK2f36+s+G8dNhcwCfYpeW
W4kAL4Mg34j0bCKOZhT9eTI=
=51jc
-----END PGP SIGNATURE-----
Tony Mechelynck
[...]
> If there's a problem affecting multiple people, there will be good and
> bad bug reports of the same issue. As long as one of the good ones gets
> dealt with, then we are OK. Recognising and closing out the bad ones
> quickly is just good use of scarce resources.
>
> Gerv
If there are good and bad reports for a single issue, then one of the good
ones should stay open and get the patches etc. as attachments, and all others
should be RESOLVED DUPLICATE shouldn't they? Or is there something I missed?
Best regards,
Tony.
--
Anxiety, n.:
The first time you can't do it a second time.
Panic, n.:
The second time you can't do it the first time.
maj...@gmail.com
> If there are good and bad reports for a single issue, then one of the good
> ones should stay open and get the patches etc. as attachments, and all others
> should be RESOLVED DUPLICATE shouldn't they? Or is there something I missed?
>
> Best regards,
> Tony.
> --
> Anxiety, n.:
> The first time you can't do it a second time.
>
> Panic, n.:
> The second time you can't do it the first time.
If something is a bad report, you usually can't tell which bug it
falls under. "My bookmarks are missing" or "my clipboard is broken"
can each be duped to at least 3 different bugs depending on the root
cause. There will be the case where someone is trying to track down a
particular issue, so they can search the incomplete bugs for the
symptoms and contact the reporters (via email or the bug report, I
don't know which is ideal) for more info and dupe it and there will be
savvy users who will watch bugzilla for similar bugs and let us know
when they see a proper report that describes their issue. Also, if
users do seek support and do enough troubleshooting to figure out that
their issue is a duplicate, they can comment back. The idea with
INCOMPLETE is to give a better place for these bugs to live (instead
of UNCONFIRMED) until they can be duped, and a better place to live
(instead of INVALID) if they can't be.
Gervase Markham
> That workflow may be ideal, but it makes quite a few assumptions that
> are unrealistic
>
> 1. A bug that was once considered NEW will not end up WORKSFORME (this
> happens all the time).
> 2. A bug that was once considered READY will not end up a DUPLICATE,
> INVALID, WONTFIX or WORKSFORME.
I don't think it makes those assumptions; I just don't think it's
absolutely exhaustive in enumerating the possible transitions.
> Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
> except that NEEDINFO more precisely describes the status of many bugs
> that are waiting on feedback from someone specifically (usually the
> reporter).
It's be interested in getting mconnor's feedback on whether he thinks
the two are equivalent. If they are, perhaps we should go in the
NEEDINFO direction, for process compatibility with other projects.
Gerv
maj...@gmail.com
don't lose what we're doing with INCOMPLETE while discussing the whole
process.
I want to check on two things,
a) are we all on board with INCOMPLETE at this point? I think
everyone is, and some would like to add NEEDSINFO as well (when it's
possible).
b) are we ok with calling it INCOMPLETE or do we want to go back to
discussing alternate names to make it more clear it's the report
that's incomplete and not work on the bug?
-Majken
Tony Mechelynck
The principle (with NEEDINFO in addition to UNCONFIRMED/NEW/RESOLVED/REOPENED
and some new resolution type) seems well-described enough. What about RESOLVED
LACKSINFO to make it clearer that the bug was resolved for want of sufficient
information?
Best regards,
Tony.
--
Whom the gods wish to destroy they first call promising.
Christopher Aillon
> Not trying to stifle discussion at all, just trying to make sure we
> don't lose what we're doing with INCOMPLETE while discussing the whole
> process.
>
> I want to check on two things,
> a) are we all on board with INCOMPLETE at this point? I think
> everyone is, and some would like to add NEEDSINFO as well (when it's
> possible).
I'm okay with the general principle of it,
> b) are we ok with calling it INCOMPLETE or do we want to go back to
> discussing alternate names to make it more clear it's the report
> that's incomplete and not work on the bug?
but not the name per my earlier posts.
Gervase Markham
> I want to check on two things,
> a) are we all on board with INCOMPLETE at this point? I think
> everyone is, and some would like to add NEEDSINFO as well (when it's
> possible).
Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
and another a status?
The current plan of record, should we ever change the statuses, is to
add a READY instead of a NEEDSINFO. A lot of discussion went into that;
I wouldn't want to change the plan until the original participants have
at least commented.
So I'm on board for a new INCOMPLETE resolution but not for status changes.
> b) are we ok with calling it INCOMPLETE or do we want to go back to
> discussing alternate names to make it more clear it's the report
> that's incomplete and not work on the bug?
I can't think of a better name.
Gerv
Andrew Schultz
> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into that;
> I wouldn't want to change the plan until the original participants have
> at least commented.
I don't remember any discussion of READY... where did that happen and
who participated?
Christopher Aillon
> maj...@gmail.com wrote:
>> I want to check on two things,
>> a) are we all on board with INCOMPLETE at this point? I think
>> everyone is, and some would like to add NEEDSINFO as well (when it's
>> possible).
>
> Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> and another a status?
Yes.
> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into that;
> I wouldn't want to change the plan until the original participants have
> at least commented.
Certainly, but AIUI, there's not much different between adding one
status vs another statuses. The reasons we opted to go for something
other than READY is because ready is a state that unfixed bugs are
almost always in. It doesn't really buy much to say a bug is ready. A
bug can be both ready to be fixed and properly triaged and assigned to
the proper person, or it can be ready to be fixed but not triaged or
assigned, etc. The reporter might say, "great, my bug is ready but
nobody's working out." But I guess I should be holding this discussion
elsewhere.
Who were the original participants so I can have another conversation
another day?
>
> So I'm on board for a new INCOMPLETE resolution but not for status changes.
>
>> b) are we ok with calling it INCOMPLETE or do we want to go back to
>> discussing alternate names to make it more clear it's the report
>> that's incomplete and not work on the bug?
>
> I can't think of a better name.
>
> Gerv
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
maj...@gmail.com
> > Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> > and another a status?
NEEDSINFO would be a status for a valid bug, so there are clear steps
to reproduce, but there is still something missing for the developer
to track down what the problem is. Maybe there are more steps
necessary than first reported, or like our Mozilla apps using 100%
cpu, it turns out it depends on hardware. It would be very handy for
people who like to do QA, they could just search for bugs with that
status and get testing. Sounds like this is very interesting as well
and should get its own discussion.
Caillon - the READY thing, I believe mconnor based it off of how
another team, which I forget (QA?) wanted to use it and he liked it.
That was a while ago though, probably time to review and see what's
still a good idea.
Ok - so the suggestions for the *resolution* are so far: INCOMPLETE,
LACKS_INFO, and INSUFFICIENT_DATA.
IMO I don't like using info or data because it can imply that
providing the info or data makes it better. I'd want to use the word
REPORT. INCOMPLETE_REPORT (or something shorter) although I'm also for
consistency, and since someone already uses INCOMPLETE and someone
else already uses INSUFFICIENT_DATA I'd want to consider them first.
Keep in mind we'd also use this for support requests, which is why I
like something a little more open ended, or focusing on the idea that
the report is just off altogether, rather than implying that there are
a few pieces of info missing. Again, what's actually wrong with the
report should be explained to the reporter wherever possible so that
they can refile properly, so there may or may not be a need to make
that clear in the resolution's name.
-Majken
Stephanie Daugherty
Hash: SHA1
Gervase Markham wrote:
> maj...@gmail.com wrote:
> Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> and another a status?
>
> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into that;
> I wouldn't want to change the plan until the original participants have
> at least commented.
>
> So I'm on board for a new INCOMPLETE resolution but not for status changes.
>
INCOMPLETE is fine as a resolution. However I'd like to see how the
workflow and requirements for that resolution are proposed - I don't
think it's going to have much effect other than being slightly more
accurate than INVALID, unless we are going to start using INCOMPLETE to
close poorly written bugs (like ones that just say "foo doesn't work"
with no other details) on sight.
- --Stephanie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGEfu6sUIV80N+s8sRAt4/AJ0bpJebtjUQz/wW4P61tDb99AENRACfVk5v
KCQ7PTsTwMhUchSTbe5KKk8=
=DsZH
-----END PGP SIGNATURE-----
Gervase Markham
> Gervase Markham wrote:
>> The current plan of record, should we ever change the statuses, is to
>> add a READY instead of a NEEDSINFO. A lot of discussion went into
>> that; I wouldn't want to change the plan until the original
>> participants have at least commented.
>
> I don't remember any discussion of READY... where did that happen and
> who participated?
This was a big discussion we had back in September 2005. I've been
trying to implement at least some of the results ever since. (Patch is
still waiting.)
http://wiki.mozilla.org/BugzillaWorkflowImprovements
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
(and previously-numbered versions)
Gerv
Gervase Markham
> INCOMPLETE is fine as a resolution. However I'd like to see how the
> workflow and requirements for that resolution are proposed - I don't
> think it's going to have much effect other than being slightly more
> accurate than INVALID, unless we are going to start using INCOMPLETE to
> close poorly written bugs (like ones that just say "foo doesn't work"
> with no other details) on sight.
That's the plan. :-)
Gerv
Andrew Schultz
> This was a big discussion we had back in September 2005. I've been
> trying to implement at least some of the results ever since. (Patch is
> still waiting.)
>
> http://wiki.mozilla.org/BugzillaWorkflowImprovements
OK, so as far as I can tell, Hixie (at some point) said there should be
a READY state. The only discussion I see is on mconnor's blog post, but
I don't see a lot of "yes, that would be great" comments. The workflow
diagram below has also changed since his initial blog post.
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
> (and previously-numbered versions)
Looking at this again, I've realized that for most bugs (not RFEs) this
really
1. renames NEW to READY
2. creates a new status between UNCONFIRMED and the new READY and calls
it NEW.
Where the difference is that READY has a testcase (currently, most bugs
where a testcase would be relevant require a testcase to be marked NEW).
A testcase is often needed to determine if the bug is valid/a
duplicate/invalid/etc (dbaron makes this point on mconnors blog). The
new difference between UNCONFIRMED and NEW is that UNCONFIRMED might be
a duplicate. Except that NEW bugs should be rechecked for duplicates.
So there's no real difference. <sigh>
From mconnor's blog post (and considering the above paragraph), is the
objective here to just insert a first-pass "I glanced at bug and I
couldn't think of a reason it shouldn't be NEW" to the triage process?
And QA noobs could do that stage of triage?
I think one of the primary effects would be that people would mark their
own bugs (or their favorite bugs) READY even if it shouldn't be. People
do this now with NEW and (on a more limited basis with clean-report).
Usually not because they're evil, but because they often think it meets
the criteria. People think 100K HTML attachments are a "testcase".
The problem I can think of that this /does/ solve is that people confirm
bugs that don't have testcases and there's no way to unconfirm them
(assuming that we could revert READY to NEW). It seems like this is a
rather silly way to solve that given that making it possible to
unconfirm a bug would be a lot simpler (unless bugzilla is too hard-wired).
Mike Connor
On 2-Apr-07, at 5:33 AM, Gervase Markham wrote:
> maj...@gmail.com wrote:
>> I want to check on two things,
>> a) are we all on board with INCOMPLETE at this point? I think
>> everyone is, and some would like to add NEEDSINFO as well (when it's
>> possible).
>
> Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> and another a status?
Yes, one is a resolution instead of a status
> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into
> that;
> I wouldn't want to change the plan until the original participants
> have
> at least commented.
Well, the plan of record assumes badly filed bugs are discarded. If
NEEDINFO can move to resolve INCOMPLETE after enough time then its
not mutually exclusive.
-- Mike
Mike Connor
On 2-Apr-07, at 11:29 AM, Christopher Aillon wrote:
>> The current plan of record, should we ever change the statuses, is to
>> add a READY instead of a NEEDSINFO. A lot of discussion went into
>> that;
>> I wouldn't want to change the plan until the original participants
>> have
>> at least commented.
>
> Certainly, but AIUI, there's not much different between adding one
> status vs another statuses. The reasons we opted to go for something
> other than READY is because ready is a state that unfixed bugs are
> almost always in. It doesn't really buy much to say a bug is
> ready. A
> bug can be both ready to be fixed and properly triaged and assigned to
> the proper person, or it can be ready to be fixed but not triaged or
> assigned, etc. The reporter might say, "great, my bug is ready but
> nobody's working out." But I guess I should be holding this
> discussion
> elsewhere.
Well, that's not entirely true. A layout bug without a reduced
testcase isn't quite READY for a developer to come in and just fix it.
I don't view NEEDSINFO/NEW as equivalent to NEW/READY, I think both
have a place in a more segmented process:
UNCONFIRMED "Firefox crashes on my favourite
site" Reporter
NEEDSINFO "What site do you crash
on?" Triager
NEW "Firefox crashes on http://foo.com/
bar" Triager
READY "Firefox crashes when X does Y, reduced testcase
attached" QA
ASSIGNED "I'm going to fix the crash
here" Dev
RESOLVED "The fix is checked
in" Dev
VERIFIED "The fix
worked." QA
-- Mike
timeless
> Reed Loden (who is responsible for maintaining the b.m.o. codebase)
> tells me that there are no plans for this to happen until a better SCM
> than CVS comes along in which to put the code. If there was a b.m.o.
> branch, he would want to restrict checkins to it, and CVS doesn't allow
> that.
confused. despot most certainly allows restricting who can check into
a branch.
Nelson Bolyard
> 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.
>
> This is basically for resolving bugs which have insufficient information
> in them. Up to now, INVALID has been used, but semantically that's not
> quite right, and it is a bit rude.
There are other cases where we use resolutions that are interpreted as
rude, where some additional resolution codes/types could be helpful.
Here are two common cases where I often wish we had other resolutions.
1. A bug is reported that is the fault of another product, not a mozilla
product. It's a real reproducible bug, but mozilla is not at fault.
It's technically invalid, since it's not a mozilla product bug, but I've
seen many reporters be offended by resolving such bugs as invalid.
I don't know of a short word/phrase that means "valid bug in some other
non-mozilla product". Maybe "non-mozilla bug" or "third party bug" or
"other product bug"?
2. A bug is reported that was a real reproducible bug in a mozilla
product, which was fixed, but we don't know what checkin fixed it.
This may be because someone files a bug on an old version of the product,
but is more commonly because a bug sat around and aged while the problem
was fixed in response to some other bug report. It's generally not worth
the time and effort to try to find the checkin that fixed it, and the bug
number for that checkin, so that we can resolve this bug as a duplicate
of the one that fixed it. So we tend to resolve those as "WORKSFORME".
But in my mind (and the minds of many bug reporters), WORKSFORME seems
to imply that this bug is not, and NEVER HAS BEEN, reproducible.
It's taken as a denial that the bug exists or ever existed. That's
unduly rude.
We don't want to mark such bugs as "fixed", because fixed implies that
we actively committed a fix for THIS bug, and the bug should point to
the fix (or the checkin comment should include this bug number).
Maybe we could call this "no longer reproducible", or "unknown fix".
Other ideas?
Tony Mechelynck
We will maybe never be able to define specific resolutions for all the
possible shades of meaning. Wouldn't it be good enough to add the specific
reason the bug was resolved in a comment?
INVALID:
- It's not a bug, it's a feature. (Explain how and why, and possibly which
setting the reporter can change in order to cure what he regards as "a bug".)
- It's a bug all right, but not a Mozilla bug. (Mention, if possible, which
non-Moz product has the bug.)
.... in both the above cases, no report should ever have been filed at b.m.o.
INCOMPLETE (currently INVALID)
- The report never contained enough information for anyone to even start
trying to reproduce the bug, and the reporter didn't deliver the info (after
some reasonable time lapse) when asked for it (and, in the proposed system,
the bug going from UNRESOLVED to NEEDSINFO).
.... the above might apply to crash reports if the crash is sporadic and the
Talkback report is either missing or doesn't contain enough info for the devs
to find out what must be corrected.
WORKSFORME:
- No one except the reporter ever succeeded to reproduce the bug
- The bug used to be reproducible all right, but at one point it disappeared
spontaneously, without any fix being applied specifically to it. (Note: As a
reporter, it has happened to me to resolve my own bugs WFM when they went away
"all by themselves" and didn't reappear for some time.)
.... in both the above cases, the bug is not reproducible with _current_
versions of the software (including currently supported branch releases).
WONTFIX:
- It may be a bug or a feature, but no-one is ever going to fix it. (Try to
find a good reason why no-one shall ever try to fix it.)
Best regards,
Tony.
--
What this country needs is a good five cent microcomputer.
Christopher Aillon
> 1. A bug is reported that is the fault of another product, not a mozilla
> product. It's a real reproducible bug, but mozilla is not at fault.
> It's technically invalid, since it's not a mozilla product bug, but I've
> seen many reporters be offended by resolving such bugs as invalid.
>
> I don't know of a short word/phrase that means "valid bug in some other
> non-mozilla product". Maybe "non-mozilla bug" or "third party bug" or
> "other product bug"?
Be careful to not say "not my problem. Go complain to someone else"
which surely isn't what the user wants to hear.
GNOME uses NOTGNOME, which I'm not a fan of. Red Hat uses UPSTREAM and
we make a point to actually file a bug with the offending product, and
reference each bug in the other so there is an actual connection. I'm
not so sure that UPSTREAM is a good naming for bmo, though.
We used to have a MOVED resolution which I believe would work out great.
It supported automatic transfers from bugscape to bmo, and some time
ago it went away. I see no reason that moves couldn't be done manually
(that's what we do at Red Hat, for example) and the resolution can be
resurrected which is friendly to the user. The only downside is that
people doing the move might need accounts on more bugzillas.
Gervase Markham
> confused. despot most certainly allows restricting who can check into
> a branch.
I'm just reporting what Reed said (possibly incorrectly). You'd need to
ask him for clarification.
Gerv
Gervase Markham
> In a few days, we plan to create a new "INCOMPLETE" resolution in
> Bugzilla, taking advantage of the new "custom resolutions" feature.
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.
In general, the larger your project, the more likely you are to have
modified statuses and resolutions on your Bugzilla. And, even though
editing resolutions is an order of magnitude easier than editing
statuses, more have edited statuses than resolutions.
Sample size: 26
Unmodified stat/res: 13
Modified statuses: 11/13
Modified resolutions: 9/13
Looking at the mods, there's a single run-away winner. 9 of the 13
projects who made a modification added a NEEDINFO (eight as a status and
one as a resolution). No other status name got added more than once.
Of the resolutions, NOTABUG/NOTOURBUG was most popular with 4, then
UPSTREAM with 3, then INSUFFICIENT_DATA with 2 (+ 1 NEEDINFO).
The last interesting point is that several projects removed the REOPENED
state, presumably instead putting bugs straight back into NEW or equivalent.
Raw data follows.
Gerv
Kernel:
Status: +REJECTED, +DEFERRED, +NEEDINFO, -UNCONFIRMED, -REOPENED
Resolution: +CODE_FIX, +PATCH_ALREADY_AVAILABLE, +WILL_NOT_FIX,
+WILL_FIX_LATER, +UNREPRODUCIBLE, +DOCUMENTED,
+INSUFFICIENT_DATA, -FIXED, -WONTFIX, -WORKSFORME
GNOME:
Status: +NEEDINFO
Resolution: +NOTABUG, +NOTGNOME, +INCOMPLETE, +GNOME1.x, +OBSOLETE,
+NOTXIMIAN, -WORKSFORME
Apache:
Status: +NEEDINFO
Resolution: No changes
OpenOffice.org:
Status: +STARTED, -ASSIGNED
Resolution: No changes
Red Hat:
Status: +NEEDINFO, +MODIFIED, +ON_DEV, +PASSES_QA, +ON_QA,
+FAILS_QA, +RELEASE_PENDING, +POST, -UNCONFIRMED,
-RESOLVED, -REOPENED
Resolution: +CURRENTRELEASE, +RAWHIDE, +ERRATA, +UPSTREAM,
+NEXTRELEASE, +CANTFIX, +INSUFFICIENT_DATA
Novell:
Status: +NEEDINFO
Resolution: No changes
Turbolinux:
Status: -ASSIGNED, -REOPENED, -CLOSED (equivalents)
Resolution: +PATCHED, +UPDATE, +NOTABUG, +WORKAROUND, +PENDING
Gentoo:
Status: No changes
Resolution: +NEEDINFO, +TEST_REQUEST, +UPSTREAM, +CANTFIX
Mandriva:
Status: +NEEDINFO, -CLOSED
Resolution: +OLD, +REPORTEDUPSTREAM
freedesktop.org:
Status: +NEEDINFO
Resolution: +NOTABUG, +NOTOURBUG
freestandards.org:
Status: +NEEDINFO, +PLEASETEST
Resolution: +NOTABUG, +NOTOURBUG
gcc:
Status: +SUSPENDED, +WAITING
Resolution: No changes
WINE:
Status: No changes
Resolution: +ABANDONED
No changes: KDE, Eclipse, Abiword, distributed.net, mozdev.org, OSAF,
ssh, Samba, Squid, Fedora (the other one), W3C, Wikipedia, XFree86.
Statuses:
NEEDINFO 8
REJECTED
DEFERRED
STARTED
MODIFIED
ON_DEV
PASSES_QA
ON_QA
FAILS_QA
RELEASE_PENDING
POST
PLEASETEST
SUSPENDED
WAITING
Resolutions (with some equivalence mappings done and obviously
project-specific stuff removed):
NOTABUG 4
UPSTREAM 3
INSUFFICIENT_DATA 2
NOTOURBUG 2 (but the same ones as NOTABUG)
PATCH_ALREADY_AVAILABLE
NOTGNOME
INCOMPLETE
GNOME1.x
OBSOLETE
NOTXIMIAN
CANTFIX
PATCHED
UPDATE
WORKAROUND
PENDING
NEEDINFO
TEST_REQUEST
CANTFIX
OLD
ABANDONED
Gervase Markham
> 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?
Gerv
Gervase Markham
> 1. A bug is reported that is the fault of another product, not a mozilla
> product. It's a real reproducible bug, but mozilla is not at fault.
> It's technically invalid, since it's not a mozilla product bug, but I've
> seen many reporters be offended by resolving such bugs as invalid.
>
> I don't know of a short word/phrase that means "valid bug in some other
> non-mozilla product". Maybe "non-mozilla bug" or "third party bug" or
> "other product bug"?
Other Bugzillas use UPSTREAM, NOTOURBUG, NOTGNOME (i.e. NOTMOZILLA), or
perhaps CANTFIX.
Does this happen regularly? I would expect to see it more in Bugzillas
belonging to projects which ship a lot of other people's software (e.g.
Linux distributions).
> 2. A bug is reported that was a real reproducible bug in a mozilla
> product, which was fixed, but we don't know what checkin fixed it.
> This may be because someone files a bug on an old version of the product,
> but is more commonly because a bug sat around and aged while the problem
> was fixed in response to some other bug report. It's generally not worth
> the time and effort to try to find the checkin that fixed it, and the bug
> number for that checkin, so that we can resolve this bug as a duplicate
> of the one that fixed it. So we tend to resolve those as "WORKSFORME".
>
> But in my mind (and the minds of many bug reporters), WORKSFORME seems
> to imply that this bug is not, and NEVER HAS BEEN, reproducible.
> It's taken as a denial that the bug exists or ever existed. That's
> unduly rude.
In this case, I'd argue that we can semantically stretch WORKSFORME to
cover this case. After all, resolutions are valid at the time they are
set. If you mark a bug FIXED, it's fixed in the current build - but it
may regress later. Similarly, if you mark a bug WORKSFORME, it works in
the current build - it may or may not have worked before. Regardless, it
works now.
Gerv
Gervase Markham
> I don't view NEEDSINFO/NEW as equivalent to NEW/READY, I think both have
> a place in a more segmented process:
>
> UNCONFIRMED "Firefox crashes on my favourite site" Reporter
> NEEDSINFO "What site do you crash on?" Triager
> NEW "Firefox crashes on http://foo.com/bar" Triager
> ASSIGNED "I'm going to fix the crash here" Dev
I'd say that it could stay in NEEDINFO until the testcase is produced,
when it could move to NEW. NEEDINFO doesn't have to be only
NEEDINFOFROMREPORTER.
But I'd be interested to know how other projects manage this.
Gerv
Gervase Markham
> We used to have a MOVED resolution which I believe would work out great.
> It supported automatic transfers from bugscape to bmo, and some time
> ago it went away.
It still exists. It's just that the implementation is a bit of a hack,
and so only supports being configured for moving bugs to one other
Bugzilla at once. We don't have a single particular Bugzilla we send a
lot of bugs to any more.
But again I wonder: is this really all that common round here?
Gerv
Andrew Schultz
> Other Bugzillas use UPSTREAM, NOTOURBUG, NOTGNOME (i.e. NOTMOZILLA), or
> perhaps CANTFIX.
>
> Does this happen regularly? I would expect to see it more in Bugzillas
> belonging to projects which ship a lot of other people's software (e.g.
> Linux distributions).
We do get these. Primarily the bugs are for misbehaving plugins (flash,
java, etc). We also get some bugs reported that turn out to be X/GTK
bugs (perhaps a similar story on windows/mac). I'm not sure about
quantity. We have 28 plugin bugs reported since Jan 2006 that are
INVALID and I suspect most are NOTMOZILLA. And there are also dupes and
bugs that didn't make it into the plugins component before being
resolved INVALID.
Andrew Schultz
> We do get these. Primarily the bugs are for misbehaving plugins (flash,
> java, etc). We also get some bugs reported that turn out to be X/GTK
> bugs (perhaps a similar story on windows/mac). I'm not sure about
Oh, and buggy extensions. Quite a few of those bugs.
Christopher Aillon
NEEDINFO is definitely not only from reporter in our bugzilla. We added
support for flags with it so you can request needinfo from someone.
When you click the NEEDINFO radio button, you are presented with a
dropdown list containing Assignee, Reporter, QA contact, and Other (with
Other being the default). When Other is selected, an entry field is
available which allows you to type in an email address of the person you
want information from.
Tony Mechelynck
> 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.
>
> 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?
>
> Gerv
Best regards,
Tony.
--
COMMENT
Oh, life is a glorious cycle of song,
A medley of extemporanea;
And love is thing that can never go wrong;
And I am Marie of Roumania.
-- Dorothy Parker
Wayne Mery
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.
Gervase Markham
> Strongly agree that using UNCONFIRMED as a synonym to "needs
> information" is not a good option.
OK, scratch that idea.
Gerv
Christopher Aillon
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
Gervase Markham
> 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
Christopher Aillon
> 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.
Gervase Markham
> 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
maj...@gmail.com
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).
Adam Kowalczyk
> - 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
Adam Kowalczyk
> - 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.
Adam Kowalczyk
> - 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.
Adam Kowalczyk
> - 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.
Adam Kowalczyk
> - 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.
Michael Lefevre
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
Tony Mechelynck
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!
Michael Lefevre
[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,
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
Gervase Markham
> 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
Gervase Markham
> 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
Michael Lefevre
On 2007-04-20, Gervase Markham <ge...@mozilla.org> wrote:
> Michael Lefevre wrote:
>> On 2007-04-18, Gervase Markham <ge...@mozilla.org> 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
Andrew Schultz
> 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
> 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.
Michael Lefevre
> 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.
I think Majken also expressed support for the idea. I thought it was more
than mconnor's own view in favour, as he did say it was the "plan of
record".
Anyway, having the resolution sound more final leaves the way open for
such a policy, or the addition of a new status, and covers better the
case of bugs that stay resolved when the reporter doesn't follow up (as
is often the case), and therefore I like the original suggestion of
"INCOMPLETE"
--
Michael
maj...@gmail.com
Gerv - should we take the naming back to the bug? I believe that's the
right place for it, plus it lets us cc people as there are specific
people who should have a stronger vote than others.
Michael, Andrew:
No, the point is that they're for the most part closed and done if
they're in this resolution. There is some leeway for the info to be
added to an early comment by the original reporter, otherwise refiling
and then duping forward is desirable. Esp if the new info is not added
by the original reporter. I've seen a couple bugs lately where the
reporter came back after 6 months to find their bug marked fixed, but
they're still seeing the issue, because we took someone else's steps
to reproduce and ran with it.
Majken (Lucy)
Someone else can always refile for the user and then dupe them forward.
Gervase Markham
> Gerv - should we take the naming back to the bug? I believe that's the
> right place for it, plus it lets us cc people as there are specific
> people who should have a stronger vote than others.
Yep.
Gerv