launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

Curtis raised this with me today while we were chatting about a few things.

We can only really assess deployability for things that are part of a
deployment; but we're tagging changes in component libraries as
qa-needstesting. For instance
https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=qa-needstesting
currently shows 10 bugs 3 of which are in lazr-js.

We came up with the following logic:
 - we can only assess deployability when we have concrete qa environments
 - small components just have a test suite
 - so unless the the project has a qa environment, or a clear
alternative qa mechanism (in its README/HACKING) file, then there is
no benefit in stalling - we should just release it if the test suite
passes.
 - And when we upgrade our version of that component in *launchpad*
(or buildbot, or whatever environment its heading into), the bug for
the upgrade, or the bug for the change if there is a task on LP, will
cover the assessment for deployability.

This should stop us sitting on inventory in component projects that we
are maintain|comaintain while they wait for an LP upgrade (which could
be stalled on any number of things).

Thoughts?

-Rob