launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

We discussed this briefly in the lead up to the November monthly
release, but it was rather close.

So I'm bringing it up again now while there is plenty of lead-room.
The new process is documented on
https://dev.launchpad.net/MergeWorkflow.

The new process, in a nutshell:
----
The Rollout (From december)
* Block deployments to all machines
* lock down devel landings (to release-critical)
* merge the qa-approved changes from db-stable to devel
* qastaging will then get the db patches included in it
* qa up through the db patch merge and nominate the revision to deploy
* unlock devel landings
* at the scheduled time do a db deploy of the nominated revision
* unlock deployments
----

This should give us a very narrow window of blocked merges: its locked
just long enough to qa all the db patches being merged. It will also
avoid breaking the qa-tagger deployment reports which currently
happens due to the revno jumping around when we do the monthly deploy
from db-stable.

However we need to make one particular change to do this: we need to
qa db-devel landings that have db patches *differently* than we have
been. Specifically we need to wait for the patch to be applied on
staging, and check that the *total* patch time for that month is
within our budget (2 hours total downtime, about 100 minutes of db
patches to allow time for other operations).

I've filed https://bugs.launchpad.net/launchpad-foundations/+bug/678289
as support for this, and we need to nominate some method for tracking
the total patch time that has built up. In the interim perhaps Stuart
can do it all by hand - as long as we only qa-ok a db patch on
db-stable when its application time has been taken into effect.

I'll be on leave at the next deployment - Francis, perhaps you could
track this becoming active?

-Rob