launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Some of you may have heard or seen me muttering about this, but I
think that monthly releases no longer fit our model of development and
deployment, so I want to change this - simplify and reduce it.

The 'release' process & cycle served many purposes for us:
 - it avoided high risk events during Ubuntu release critical periods
 - it signalled the exposure of new features to users
 - gave a venue for events requiring downtime (such as security
updates, hardware maintenance etc)

With the ReleaseFeaturesWhenTheyAreDone (continuous deployment)
project all but done, the benefits we get are changed.

Now, the monthly cycle gives us:
 - deploys of *QA'd* database changing code
 - a window to do downtime maintenance on machines

As we wrap up the continuous deployment work we'll be able to do even
more maintenance without downtime, further reducing the amount of work
we do during the monthly cycle.

In particular, note that:
 - we no longer have a qa rush: things that are QA ok when the time
comes get deployed, things that aren't are carried over / rolled back
(same as changes in devel) (Remember - our next db deploy is april 6th
- if its not qa'd in db-stable by the 3rd april (monday oceania), it
won't be carried into the release).
 - we deploy only a small number of revisions on the downtime deploy
 - we are stopping the practice of doing changes other than the db
deploy during the downtime window (by making things changable without
downtime)
 - we don't 'release' anything during downtime deployments.

This leaves the following actions needed during the deploy cycle:
 - far enough ahead of the deploy window for us to get through
buildbot, and again if we choose to rollback, merge db-stable's
highwater qa revision to devel.
 - Discuss deploy windows with stakeholders and maintain the calendar
 - liase with losas to let them know the revision of stable that we
are deploying a few hours before the deploy.

So, I propose the following:
 - Francis should do deployment window discussions.
 - We make the 'please merge db-stable rev XXX to devel' a team
responsibility, just like nodowntime deploys. I'll happily put the TA
team up as a backstop for this - we'll make sure it happens.
 - Likewise, we make informing the LOSA team of the revision to stage
ready for the downtime deploy a team responsiiblity (again, with TA
acting as a backstop to ensure it happens).
 - We stop tagging bugs with milestones - we deploy only a few changes
in each deploy, and we don't do feature releases at the same time. We
also will be doing  *more* downtime deploys as we get faster DB
deployments sorted out.

What-do-you-all-think?
-Rob