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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
