Trunk

Not logged in - Log In / Register

Revision 8 as of 2009-08-11 04:12:11

Clear message

Where's trunk?

This page describes the "master" branches for Launchpad development. Please ask for help immediately if you have any questions.

TODO: This page is still in progress; I'm still bringing material over from https://wiki.canonical.com/Launchpad/Experiments/DBDevel and rearranging. I'll finish out bug #408069 when done. -kfogel

Launchpad has four master branches (this is unusual; most projects only have one). All four are owned by launchpad-pqm, the Patch Queue Manager. They are:

  1. devel Where most development takes place (except anything that involves changing the database schema; see below).

  2. db-devel Changes that modify the database schema get merged here first. Note: this is also the default stacking branch for other Launchpad branches.

  3. stable What edge runs; fed by regular merges from the devel branch. This is also what we roll out to production servers on each release.

  4. db-stable What staging runs; fed by regular merges from the db-devel branch.

First, Look at the Pretty Pictures

Diagrams might be the best way to understand this. (If they don't work, there's text afterwards, don't worry.)

codeflow.png

Below, we break the process down a bit with a different diagramming approach. Here's what happens when you submit to devel:

db-devel-normal.png

Where are the expected potential problems in the process? Glad you asked!

db-devel-problems.png

All of this is really to support being able to submit directly to the db-devel branch.

db-devel-direct.png

Let's Try That in Words

Database changes can be destabilizing to other work, so we isolate them out into a separate branch (db-devel). Then there are two arenas for stabilizing changes for rollout to production: stable (which ends up on edge and is fed from the devel branch), and db-stable (which ends up on staging and is fed from the db-devel branch).

In summary:

Problems that can occur

Where to Send Merge Requests

Merge requests that do any of the following should be sent via PQM to the db-devel branch:

All other developer merge requests for the launchpad tree should be addressed to the devel branch.

The current buildbot-poller.py script on the PQM box monitors buildbot to discover what revisions have passed the tests. When a new revision is "blessed" by buildbot, the script copies it over to stable. The poller script generates a merge request to PQM for merging the blessed revision with the db-devel branch. It is also responsible for checking a new buildbot build testing db-devel. The poller will copy revisions of db-devel that buildbot blesses to db-stable.

Staging releases and production releases should run code from db-stable. edge should continue to run code from stable.

When a production release is made, the db-stable code should be pushed to devel and stable before opening devel back up to commits (that is, turning off release-critical mode, or something even stricter). At the moment, we expect this push to be a manual job for LOSAs after a software maintenance.

Problems with the automated merge requests are sent to the Launchpad list (TODO: which list?). The PQM merge request is signed with a key associated with the Launchpad list email address; PQM will send any merge failure email to the Launchpad list.

When fixing a [testfix] or a merge error, reply to the email that was sent to the mailing list with the resolution of the issue.

When the merge of staging -> db-devel does not work automatically, it should be done manually and submitted. The tests do not need to be run (rationale: the bots don't run the tests when the do it automatically, and the failure messages can clutter up the ML really fast.)

How do I submit to db-devel?

cd ~/canonical/lp-branches
bzr branch lp:~launchpad-pqm/launchpad/db-devel mydbbranch
cd mydbbranch
./utilities/link-external-sourcecode ../trunk
make build
make schema

...hack until ready to submit...

bzr pqm-submit --submit-branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel -m '[r=so-and-so] improve frobnitz'

Instead of that last line, here's a nice variation from abentley:

Then the last line can be just this:

bzr dbsubmit -m '[r=so-and-so] improve frobnitz'