launchpad-dev team mailing list archive

[Henning Eggers <henning.eggers@xxxxxxxxxxxxx>]

Am 01.11.2010 23:58, schrieb Robert Collins:
> Now that we're doing RFWTAD, I'd like to change our release process.

Yes, that is something that's on my mind currently ... ;-)

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

I have been thinking. Since we now have continuous roll-outs for code changes,
the release really is mainly about rolling out database changes. I think the
process should reflect that and I think that we can get away without closing
pqm for devel at all. It looks like this is similar to your plan since that
does not mention locking down db-devel.

 1) Stop landings from stable to db-stable and continuous roll-outs to
production.[*] Make sure that the same revisions have been merged in db-devel
as have been rolled.out to production.

 2) At the same time switch PQM to release-critical for db-devel landings. Any
release-critical landings will have to go to db-devel and should probably be
landed into devel, too, if they don't include db changes.

 3) Make sure staging db is up-to-date and all revisions QA'd.

 4) When db-stable has settled down, pick the release revision of db-stable
and merge that into production and into devel/stable.

 5) Now PQM can be re-opened for db-devel landings and landings from stable
into db-stable can resume.

 6) Roll-out the production branch, see that all works as expected.

 7) Re-enable continuous roll-outs.

 [*] That is the cut-off point for landings in the upcoming release. That
deadline is not as bad as the old PQM closure because continuous roll-outs
will resume directly after the release.

I am not sure about timing but I think for the first iteration we should map
it to our old schedule.  1) and 2) would happen Friday night, 3) over the
week-end and Monday, 4) and 5) on Tuesday, 6) Wednesday 10 UTC, and 7)
Whenever the release has been declared a success.

Eventually we should stream-line the process to keep the interruption of
continuous roll-outs as short as possible.

> 
> This will have the following impact:
>  - we'll see a clean db upgrade happen with all the db patches

Hm, I don't know what that means exactly.

>  - code will converge faster (because we don't wait for the release to
> have db-devel merged to devel)

This proposal may be even faster a bit faster and less disruptive for the
developers.

>  - revnos in production will not jump around

Can we not avoid that by simply merging db-stable into production instead of
replacing it (like we did until now, I think)?


I wanted to announce the PQM closure to the developers today but it would have
to be different if we adopt any of these changes.

Thoughts? What did I miss?

Henning