launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Right now we rollout two different production branches:
stable to edge
production-stable to everything else
and production-stable is source from db-stable

(production stable is a private branch because if we have a CVE we
need to apply we must embargo that per the CVE rules until its
released).

To try and keep things consistent we merge
stable->db-devel

automatically.

But, this means that there can be a bit of a disconnect at release
time, so I'd like to propose that rather than having the branch with
*db changes* -closer- to production
(devel->stable->db-devel->db-stable->production), we should instead
have it -further-away- (db-devel->devel->stable->production).

This won't work right now because we have lots of changes in db-devel
and db-devel alone.

But! our shiny new workflow is nearly here. And when its here, we'll
be rolling out stable to all the appservers, and eventually all the
backends too.
So, if something goes into db-devel, it should *only* be something
that has to wait for downtime. There is no reason to put UI changes in
db-devel, because they can come in a day after the downtime via the
new process.
So the only things that go into db-devel should be db patches that
can't be deployed mid-cycle, and that means that its going to be a
tiny delta, rather than the occasionally awesome one we get today.

Also cherrypicks will be just 'deploy stable' - the main thing will be
agreeing to have downtime to do the CP (because things that don't need
downtime we'll be deploying as a matter of course).

This might not be entirely focused as a concept yet :) Please poke at
it to help me get the confusion gone.

In summary:
 - When RFWTAD land
 - DB patches *only* to db-devel
 - db-devel merges to devel at the start of release week, once.
 - devel merges to db-devel continually
 - its DB patches *only* so no huge messy conflicts.
 - We QA the resulting branch on daily-staging
 - We deploy stable

-Rob