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

Janek Bevendorff jbev_kdelists at refining-linux.org
Tue Aug 28 10:20:53 UTC 2012


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


On 08/28/2012 11:30 AM, David Edmundson wrote:
> Does this actually change anything other than the words. Would we 
> still expect all resolved bugs to be verified?

Well, yes and no.
There is a pretty good documentation for the Bugzilla 4 workflow here:
http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
It does change a little more than just the words. It gets rid of
useless but possible combinations of status + solution such as
NEEDSINFO WORKSFORME etc. and reduces possible confusion a lot.

First of all the status NEW is replaced with the status UNCONFIRMED
(which is already much clearer). Then after a triager or developer was
able to reproduce it, he marks it as CONFIRMED. Bugs that are being
worked on are IN_PROGRESS and once they have been fixed (or it has
been decided not to fix them at all) they are RESOLVED. RESOLVED is
also the only status that has additional solutions such as FIXED,
DUPLICATE, WORKSFORME etc.
That could be the end, but if someone from the QA team can verify that
a bug has actually been fixed he can set the status to VERIFIED.

That's it. Pretty much straight forward, no room for confusion.
The current workflow, however, is pretty hard to understand. No one
really knows what CLOSED actually means, especially because the link
"Mark as duplicate" also uses RESOLVED DUPLICATE, not CLOSED
DUPLICATE. And just to ask the obvious: what would be the difference?
Would CLOSED DUPLICATE mean that a QA guy verified that it is actually
a duplicate? Isn't that something a dev can decide best? If the dev
decides in this matter, why doesn't he decide in other cases too. Why
does a duplicate actually need to be verified etc. etc.

And to increase the confusion even more: if you look at the status
documentation inside bko thoroughly, you'll notice that it actually
documents the new Bugzilla 4 way of doing things and not the workflow
we're currently using (or trying to use).

So converting the database to the Bugzilla 4 workflow would IMHO be
the best solution. It would mean some hard work in the beginning but
I'm pretty sure it would pay off.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQPJuFAAoJEN/wwJ2g68YYdCEIALQrrlx7eqppmXN6iABPL95u
Il5fwBAIx7hTPBGvx14JNF7jFOPyGjBTkPJWPH4NCOue3gh+iVo3d+X69UxVkZ96
AifErkEceOxm3FO30p33p+X9A4Gw3/3Eyrblz42zh9c2gjUvCUReysMv9mRmuqEe
Bs1No5KDjNxNAJbd461gAAb/DTGwljf4oZEAhzaysJcN0Ex3CuHgRTzrNskdz6Di
AH4QRxie8duiJ9KEVhr5CneGcWOIXFGx7wmbvXPFBuIJAGU/EZ1UmuWJ/xh8pvUK
yWQ8gqagOFzDyN+08lI/Nnxsbo2q7AaTA25axT2ALyZPdPXFp/WSp/80Uqm6dPk=
=f7NY
-----END PGP SIGNATURE-----


More information about the Kde-testing mailing list