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

Stephanie Erin Daugherty-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gervase Markham wrote:

> [hidden email] 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-----
_______________________________________________
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 Andrew Schultz-2
Andrew Schultz wrote:
> 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
_______________________________________________
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 Stephanie Erin Daugherty-3
Stephanie Daugherty wrote:
> 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
_______________________________________________
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
In reply to this post by Gervase Markham
Gervase Markham wrote:
> 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).

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

Mike Connor-4
In reply to this post by Gervase Markham

On 2-Apr-07, at 5:33 AM, Gervase Markham wrote:

> [hidden email] 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
_______________________________________________
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

Mike Connor-4
In reply to this post by Christopher Aillon

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

timeless-3
In reply to this post by Gervase Markham
On Mar 28, 6:42 pm, Gervase Markham <[hidden email]> wrote:
> 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.

_______________________________________________
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

Nelson Bolyard
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.
>
> 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?

_______________________________________________
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
Nelson Bolyard wrote:

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

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.
_______________________________________________
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 Nelson Bolyard
Nelson Bolyard wrote:
> 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.
_______________________________________________
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 timeless-3
timeless wrote:
> 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
_______________________________________________
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:
> 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

_______________________________________________
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
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?

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 Nelson Bolyard
Nelson Bolyard wrote:
> 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
_______________________________________________
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 Christopher Aillon
Mike Connor wrote:
> 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         "Crash when X does Y, reduced testcase attached" QA
> 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

_______________________________________________
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 Nelson Bolyard
Christopher Aillon wrote:
> 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

_______________________________________________
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
In reply to this post by Gervase Markham
Gervase Markham wrote:
> 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
[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:
> 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.

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

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

> Mike Connor wrote:
>> 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         "Crash when X does Y, reduced testcase attached" QA
>> 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.

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

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345