On 14/02/11 13:36, Martin Pool wrote: > That makes sense to me, though it does seem like qa-deployable is very > similar in meaning to 'qa-ok and Triaged'. >
Yes, that's a good point. And perhaps one which serves to help illustrate part of the issue? The bug's tags (as used in the current discussion to reflect QA status of the associated revision) and status attributes (as used for bug lifecycle) should be orthogonal I think. To me, it's not acceptable in some cases to merely have to look at the QA tags to get the relevant information (eg tag="qa-bad" means what it means without having to look elsewhere), whereas in other cases, you need to also look at the value of what should be an unrelated bug attribute to understand what's happening (so currently tag="qa-ok" has different meanings depending on the value of the bug's status attribute). Unless I'm mistaken, that's not simple, nor unambiguous, nor intuitive etc etc. > Describing it as 'deployable' seems to make it even more clear the > status applies to the revision not to the bug. > Yes, the qa-deployable tag does make that clear, and helps keep what to me are separate concerns, well... separate. So adding the qa-deployable tag means one can look at a single attribute on a bug (the tag value) to unambiguously know what's happening with the associated revision. And it's then perhaps easier to automate bug handling etc For example, perhaps the qa tagger could automatically set the status of a bug back to Confirmed (from In Progess) if the qa-deployable tag is set, since the implication is that there's still and issue to fix, else it would have been tagged qa-ok. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
