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 _______________________________________________ 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
