-----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----- _______________________________________________ Kde-testing mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-testing
