On Fri, Apr 15, 2011 at 7:28 AM, Robert Collins <[email protected]> wrote: > 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). >
This makes sense to me. What are the next actions? jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
