launchpad-dev team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

On 15/09/11 18:44, Stuart Bishop wrote:
> On Thu, Sep 15, 2011 at 7:47 AM, Robert Collins
> <robertc@xxxxxxxxxxxxxxxxx> wrote:
> 
>> To land a schema change in db-devel, any dependent python changes must
>> be *DEPLOYED* to all services that execute the changed code. Not
>> landed. Deployed.
> 
> I think we are going to need a better way to track this. Its bad to
> let branches linger in either the pre-MP or post-MP stages as they
> lose their way for a variety of reasons. Or worse, get landed by
> someone like me who is not aware of the dependencies. And of course,
> there will be mistakes where a service assumed updated was not updated
> because of cowboyed patches or similar.
> 
> Perhaps we will only deploy a db-devel release when we know its
> corresponding stable revision has been deployed everywhere? This could
> be flagged in the deployment report, assuming we have some easy way of
> knowing what revision is deployed where (we need this bit anyway, and
> have it in a somewhat unreadable format).

We always check before deploying, yes. But once something is in
db-devel, everything behind it is blocked! Many patches don't have such
sequencing constraints, so holding them up behind a patch that does
during a multi-day stable deployment blockage (like the one we're in now
with garbo-frequently) is not ideal.

In this particular case, it was pretty bad: the DB patch broke old
versions of oops-prune, so it needed *every* host to be updated. Most
will be OK with just nodowntime, but this case was worse.

Attachment: signature.asc
Description: OpenPGP digital signature