Re: Bugzilla summary
- From: Martin Baulig <martin home-of-linux org>
- To: rms39 columbia edu (Russell Steinthal)
- Cc: gnome-hackers gnome org
- Subject: Re: Bugzilla summary
- Date: 21 Nov 2000 16:03:27 +0100
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)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]