launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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

On 11-02-13 11:27 PM, Ian Booth wrote:

> 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.

I agree, and I've written up a LEP, which jml has approved, for
deployability-oriented QA that tracks the status of revisions, not bugs:

https://dev.launchpad.net/LEP/DeploymentQA

> 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

I think the deployment report could be a good place to get all this
information, but it needs improvement.

> (so currently tag="qa-ok" has
> different meanings depending on the value of the bug's status
> attribute).

Not in the release manager's perspective, IMHO.  As RM, I didn't really
care about which bugs were fixed, I cared about which revisions were
deployable.  As long as QA-ok means "deployable", I'm happy.  If
renaming QA-ok to QA-deployable or changing the definition gets us
there, I'm happy.

> Unless I'm mistaken, that's not simple, nor unambiguous, nor
> intuitive etc etc.

I agree with you that "deployable" and "fixes the bug" are two different
axes, but representing two axes with one value seems unlikely to work well.

> 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.

To me, it looks like database denormalization.  It means we have to
track the "fixed" status of the bug in two places, the bug "status"
attribute and the QA tags.  I would much rather completely remove the
"fixes the bug" aspect of QA tags entirely, since we already have a
place for that information that is standardised in Launchpad.

> 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

We don't use Confirmed.  Did you mean "Triaged", or are you suggesting
we start using it?

> (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.

I agree that the bug status and QA tags should be orthagonal, and
therefore I disagree with this.  I say QA tags should only indicate
deployability.  We can *rename* qa-ok to qa-deployable if that helps.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ZR0EACgkQ0F+nu1YWqI1mnwCghK8FiW+tQAp7poJCCo9CilRA
BlIAn3lKlQ41HM81kZKmuKvFP/F3ALu0
=XhWB
-----END PGP SIGNATURE-----