On 15/09/11 18:44, Stuart Bishop wrote: > On Thu, Sep 15, 2011 at 7:47 AM, Robert Collins > <robe...@robertcollins.net> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
