launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

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
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.