launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

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.