Re: Bugzilla summary

[Martin Baulig <martin home-of-linux org>]

rms39 columbia edu (Russell Steinthal) writes:

> Personally, I think there are two distinct states here:
> 
> INCOMPLETE ---- I don't have enough information to determine if this 
>                 bug is real or not, but let's keep it around just in 
>                 case.
> 
> WORKSFORME ---- I have tried to reproduce this bug without success, 
>                 even under the (possibly complete) circumstances 
> 		provided by the reporter.

Well, I'd see INCOMPLETE as a resolution, not as a state. So you actually
close a bug report if you set its state to INCOMPLETE - but the submitter
can reopen it at any time.

For WORKSFORME, I think a bug report is either INVALID or INCOMPLETE, but
never WORKSFORME - either it was just crap in is thus INVALID or the submitter
has a real problem and you cannot just close it as WORKSFORME if it works
for you - you need to close it as INCOMPLETE since you were unable to help
this person fix his problem.

> A related question: what is the preferred status for bugs reported on 
> platforms which the maintainer doesn't have access to?  I'd like 
> some way to leave them in the system, possibly as unconfirmed, but 
> also ask for confirmation (and additional information) from those who 
> have access to that platform.  Would that be keyword: HELPWANTED?  Or 
> something else?

I think the correct solution is

a) if it's a bigger package and you're not the only maintainer, keep it
   as NEW and set the `help-wanted' keyword - maybe some of the other
   developers of this package are able to fix it.

b) if you're the only maintainer and you think there's at least a little
   chance that you'll ever be able to fix it or find someone who helps you
   with this, set it to ASSIGNED and set the `help-wanted' keyword.

c) if you're really unable to fix it, close it as REMIND and set the
   `help-wanted' keyword.

d) only close it as WONTFIX if it is either technically impossible to fix
   the bug or if the platform/os is not supported by your application and
   you don't plan to support it in future.

To give a little examples (I'd set the `help-wanted' keyword for all of them):

I'd set a LibGTop bug for one of the free BSD variants (FreeBSD, OpenBSD,
NetBSD etc.) to ASSIGNED to me, set its priority (if we decide to have a
Priority field) to the lowest possible value. Reason: I may be able to get
such a free BSD system at some time far in the futures so I can fix it, but
I don't plan to install such a system right now just to fix the bug.

I'd keep a LibGTop bug for any version of Solaris in the NEW since I don't have
such a system nor do I plan to get such a system, but there are good chances
that someone else can fix it.

I'd close a LibGTop bug for any version of OSF/1 (or however you call this
system) as REMIND since the OSF/1 port is currently unsupported, but I may
be able to get on such a system where I can fix it.

I'd close a LibGTop bug for any version of HP/UX or AIX as WONTFIX and won't
set the `help-wanted' keyword since there is no port to this platform yet.

Hmm, this reminds me that we need to decide whether we want to have a
Priority: field (which should only be set by the maintainer) or not.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)