We've merged rev 10381 (the highest qa'd revision) of db-stable to devel and its wending its way through buildbot now.
There were two revisions - a publisher change and comment hiding for questions - that were in db-stable but not qa'd. They have *not* been included. However, as neither contain DB changes, they can both be landed again on devel once we qa past the db-stable merge; and then qa'd etc and deployed subsequent to the complete downtime deploy. As part of making the downtime more reliable we're going to make the db downtime be precisely that: we'll deploy the db changing revision *only* during the downtime window, and do a regular nodowntime deploy subsequent to that. If you are changing a service which isn't part of the nodowntime set, it either needs to go only through db-devel, or organise a *partial downtime* window for it via mrevell. My strong preference is *partial downtime* because the DB downtime deploys are the single most risky event we have: making that go really well is crucial for decreasing the duration of complete downtime. Cheers, Rob https://dev.launchpad.net/Downtime for the definitions of complete and partial downtime. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
