Use of CLOSED in Bugzilla (was) Re: [Bug 284853] ...

Janek Bevendorff jbev_kdelists at refining-linux.org
Tue Aug 28 16:17:21 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 

On 8/28/2012 5:44 PM, Myriam Schweingruber wrote:
>
> There you are already wrong, as currently we have UNCONFIRMED by
> default, what we need to do is replace the wording from NEW to
> CONFIRMED, that is already a request made some time ago buy several
> triagers:
>
> https://bugs.kde.org/show_bug.cgi?id=195305
Sorry, I meant CONFIRMED, of course. Replacing NEW with UNCONFIRMED
wouldn't make much sense. :-)
The Bugzilla 4 workflow would replace NEW with CONFIRMED. BTW that's
exactly the bug report I mentioned before.

> Wrong again, as we absolutely need the NEEDSINFO status you seem to forget in your workflow, without
this is just not doable, and this is definitely another status with
several possibilities.
I wouldn't say that I'm wrong here. NEEDSINFO is missing in that
workflow, yes, but since those status messages can be freely edited
(IIRC) it shouldn't be a problem to add that. It would be something
between UNCONFIRMED and CONFIRMED. But since this is not a closed bug, I
would remove the resolution field for that which we're currently using.
Although we can specify what's missing (e.g. NEEDSINFO BACKTRACE), I
would simply remove it. Only having NEEDSINFO without a resolution
should be enough. And because you write in the comment what's missing,
it should be clear enough. By removing the resolution you'd also remove
the possibility to search specifically for NEEDSINFO WHATEVER, but
honestly I don't know why someone should do that (prove me wrong, but I
don't see any advantage). NEEDSINFO reports that haven't been answered
for some time are worthless anyway, regardless of whether it's NEEDSINFO
WAITINGFORINFO or NEEDSINFO BACKTRACE or something else. They should be
closed after some time regardless of what's missing.
Having a resolution for NEEDSINFO is only confusing because a) it
creates many useless combinations as mentioned before, b) it's not
actually a closed bug, therefore having a resolution is wrong in itself
and c) it is a status between UNCONFIRMED and CONFIRMED which is another
reason not to have a resolution (just for the sake of consistency and to
keep the bug workflow straight).

> I agree with you for the rest indeed, although the current status
> called RESOLVED is also a very misleading wording, I would prefer
> CLOSED much more as it wouldn't suggest for example an existing
> resolution when closing something as RESOLVED -> DOWNSTREAM.
Well yeah. If we keep the current way of doing things I'd definitely
like to have RESOLVED removed using CLOSED instead. If we should adapt
the Bugzilla 4 though, I'd leave it as is, since a bug is not really
closed before it's VERIFIED.

> What we certainly don't need is having both CLOSED and RESOLVED,
> simply because we don't have the manpower to go through all bugs with
> the RESOLVED status and verify them to be really closed.
That's one more reason not to stick with the current status names.
Having CLOSED but not using it makes it look like we're never finishing
things. Having RESOLVED and VERIFIED instead would make that point a
little clearer. Although bugs are not really closed until they are
VERIFIED (as I said above), it's clear that the bug has been being
worked on and a decent fix exists. It only hasn't been verified by QA,
which might or might not come in the future.

In general the Bugzilla 4 stuff is nothing more than just renaming and
cleaning up stuff:

UNCONFIRMED -> stays as is
NEW -> CONFIRMED
ASSIGNED -> IN_PROGRESS
RESOLVED -> stays as is
CLOSED -> VERIFIED
REOPENED -> removed, bug becomes either CONFIRMED or UNCONFIRMED when
reopened
NEEDSINFO -> not there, but we can add it (should not be a final status,
though, therefore shouldn't have a resolution IMHO)


Cheers
Janek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJQPO8RAAoJEN/wwJ2g68YYNBIIAM7xqOJyz+skS/3g2MDzlkA8
b+e97how8VFeLhA8RyqEta8uzLgG0EiZLPlRJzWDaUCicUZTKgVkN/eKkANjy3+/
qwfcrXE3ffcE9c9Nso7zfj5Xwl57gCS+WhivsKKG0HGSA3MEK+yqUuqQB9SEaT8X
/jGezmbxlkXRrCO3vZChaN+y2W1iQlLog5s1hnTDHSCOkPBR4eIFOk/qGm81YUZr
IleOQBtCLRSvXzSq3Lw93B9CN8op6Zmoirs0pS5/dyJH8bTN1KbwS7/G2t1s9z52
VjBsgPV3uThcP3pkhe7V1q8jMr5UiakDOuHPn+8KvK4IUeQE3wUvDBQxbO5dG54=
=/qlm
-----END PGP SIGNATURE-----



More information about the Kde-testing mailing list