launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Fri, Apr 15, 2011 at 7:28 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> 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