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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
