On November 1, 2010, Robert Collins wrote: > Now that we're doing RFWTAD, I'd like to change our release process. > > From: > lock down devel landings (to release-critical) > lock down db-devel landings (to release-critical) > while unqaed: qa > choose the rev of db-devel > unlock things > @scheduled time: release > merge db-devel to devel > > To: > merge db-devel to devel > lock down devel landings (to release-critical) > while unqaed: qa > choose the rev of devel > unlock things > @scheduled time: release > > This will have the following impact: > - we'll see a clean db upgrade happen with all the db patches
Is that because we are going to run the upgrade on qastaging? Can we handle this yet? I'm not sure it's that different that what we have now, as we do see the clean db upgrade happen with all the db patches on staging on the Saturday. I can see that if the db upgrade is made on qastaging on Friday, it is marginally better since it doesn't happen over the week-end. But it will do it with a database lagged way more than staging full restore. > - code will converge faster (because we don't wait for the release to > have db-devel merged to devel) > - revnos in production will not jump around > The only issue you missed out is that as soon as we merge db-devel to devel, we lose our ability to deploy fixes to production without a cow-boy. I think that may be still a problem (it's required often enough to not be dismissed.) -- Francis J. Lacoste [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
