launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

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.