launchpad development|
Size: 7620
Comment: Bring over a lot of material from internal wiki.
|
Size: 8417
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| '''''TODO:''''' ''The relationships between these four branches are given in this internal wiki page, along with great diagrams: https://wiki.canonical.com/Launchpad/Experiments/DBDevel . I am transferring that information over right now. Also, I'll finish out [[https://bugs.edge.launchpad.net/launchpad-documentation/+bug/408069|bug #408069]] when done. -kfogel'' | ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
| Line 9: | Line 9: |
| 1. '''[[https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel|devel]]''' Where most development takes place (except anything that involves changing the database schema; see below). 1. '''[[https://code.edge.launchpad.net/~launchpad-pqm/launchpad/db-devel|db-devel]]''' Changes that modify the database schema get merged here first. ''Note: this is also the default [[http://code.mumak.net/2008/10/stacked-branches-and-new-world.html|stacking branch]] for other Launchpad branches.'' 1. '''[[https://code.edge.launchpad.net/~launchpad-pqm/launchpad/stable|stable]]''' This is what we roll out to production servers when we do a release. 1. '''[[https://code.edge.launchpad.net/~launchpad-pqm/launchpad/db-stable|db-stable]]''' ??? (see below) |
1. '''[[https://code.launchpad.net/~launchpad-pqm/launchpad/devel|devel]]''' Where most development takes place (except anything that involves changing the database schema; see below). 1. '''[[https://code.launchpad.net/~launchpad-pqm/launchpad/db-devel|db-devel]]''' Changes that modify the database schema get merged here first. 1. '''[[https://code.launchpad.net/~launchpad-pqm/launchpad/stable|stable]]''' This is fed by regular merges from the '''devel''' branch, and is deployed to [[https://edge.launchpad.net/|edge.launchpad.net]] daily. 1. '''[[https://code.launchpad.net/~launchpad-pqm/launchpad/db-stable|db-stable]]''' This is fed by regular merges from the '''db-devel''' branch. It is deployed to [[https://staging.launchad.net|staging.launchpad.net]] daily, and deployed to [[https://launchad.net/|launchpad.net]] on each release. |
| Line 14: | Line 14: |
| = Understanding the db / non-db distinction: = | In summary: '''db-stable''' is the post-test-run counterpart of '''db-devel''', and '''stable''' is the post-test-run counterpart of '''devel''', where ''"post-test-run"'' means that once code hits foo-devel it is only cleared into foo-stable if the buildbot test runner succeeds. |
| Line 16: | Line 16: |
| We want to be able to keep having [[https://help.launchpad.net/GetInvolved/BetaTesting|edge]] updates during Week 3 and Week 4 (in the month-long development cycle). This means that our users are able to get more bug fixes during the whole of the cycle and we get a broader QA coverage. |
db-devel is also the default [[http://code.mumak.net/2008/10/stacked-branches-and-new-world.html|stacking branch]] for other Launchpad branches, as it usually has almost all of the revisions that are present in any of the four trunk branches. If you want to know how all of this works behind the scenes, read [[Trunk/Glue]] (after reading the rest of this page). = 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.) {{attachment:codeflow.png}} Below, we break the process down a bit with a different diagramming approach. Here's what happens when you submit to '''devel''': {{attachment:db-devel-normal.png}} Where are the expected potential problems in the process? Glad you asked! {{attachment:db-devel-problems.png}} It is also possible to submit directly to the '''db-devel''' branch. {{attachment: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 deployment: '''stable''' (which ends up on [[https://edge.launchpad.net|edge]] and is fed from the '''devel''' branch), and '''db-stable''' (which ends up on [[https://staging.launchpad.net|staging]] and is fed from the '''db-devel''' branch). In summary: |
| Line 26: | Line 48: |
| * When changes are approved by buildbot to go from '''devel''' to '''stable''', a script also generates a PQM request to merge '''stable''' with '''db-devel''', sent as if it came from the Launchpad list. The Launchpad list will be informed of merge failures, and launchpad developers will collectively be responsible for correcting them. ('''''TODO: is this some internal list? Hmmm.''''') | * When changes are approved by buildbot to go from '''devel''' to '''stable''', a script also generates a PQM request to merge '''stable''' with '''db-devel''', sent as if it came from the Launchpad list. The Launchpad list will be informed of merge failures, and launchpad developers will collectively be responsible for correcting them. ('''''TODO: is this some internal list? Hmmm.''''') |
| Line 28: | Line 50: |
| * Staging runs '''db-stable'''; edge runs '''stable'''. We will deploy the production site from '''db-stable'''. (After a deployment, '''db-stable''' is manually pushed to '''devel''' and '''stable'''.) | * Staging runs '''db-stable'''; edge runs '''stable'''. We will deploy [[https://launchpad.net|launchpad.net]] site from '''db-stable'''. (After a deployment, '''db-stable''' is manually pushed to '''devel''' and '''stable'''.) |
| Line 30: | Line 52: |
| * When '''devel''' ''or'' '''db-devel''' get a test failure, we go into `[testfix]` mode ''for both branches''. If only one branch is broken, a `[testfix]` to the broken branch that then makes the tests pass will reopen both branches for normal use. | * When '''devel''' ''or'' '''db-devel''' get a test failure, we go into `[testfix]` mode ''for both branches''. If only one branch is broken, a `[testfix]` to the broken branch that then makes the tests pass will reopen both branches for normal use. |
| Line 36: | Line 58: |
| == Process under experiment == | = Where to Send Merge Requests = |
| Line 59: | Line 81: |
| 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.) | When the merge of '''stable''' -> '''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.) |
| Line 61: | Line 83: |
| == What's that, you say? == By popular demand, let's try pictures. This summary might be all you need. {{attachment:codeflow.png}} If you want more, now we'll break the process down a bit with a different diagramming approach. So, here's what the old process looked like when you submitted to do the '''devel''' branch. {{attachment:db-devel-old.png}} Here's what happens when you submit to '''devel''' now. {{attachment:db-devel-normal.png}} Where are the expected potential problems in the process? Glad you asked! {{attachment:db-devel-problems.png}} All of this is really to support a new story: being able to submit directly to the '''db-devel''' branch. {{attachment:db-devel-direct.png}} == How do I submit to db-devel? == |
= How do I submit to db-devel? = See also WorkingWithDbDevel. |
| Line 117: | Line 114: |
| As another alternative, there is a version of ec2test that can be used to test against '''db-devel'''. This is in beta, so it is not on the main branch. Check out {{{lp:~garyposter/lp-dev-utils/alt-lp-branch}}} and try that version of ec2test. You should be able to use {{{ec2test -b launchpad=db-devel}}} to test against and submit to '''db-devel'''. Please report back successes and failures to [[mailto:gary.poster@canonical.com|Gary]]. | '''''XXX: Shouldn't this be unnecessary if you have `~/.bazaar/locations.conf` configured right?''''' |
| Line 119: | Line 116: |
| See also [[Launchpad/WorkingWithDBDevel]]. | = FAQ = == Can I land a testfix before buildbot has finished a test run that has failed or will fail? == Yes you can, and please do if appropriate, because this will mean that other developers will not encounter [testfix] mode at all. == If db-devel is broken, does that mean that devel is also in [testfix]? Why? == Yes, as mentioned before, there is a single [testfix] mode for PQM. That is because we regard this as a stop-the-line system breakage. == What happens if the automatic merge from stable to db-devel fails? == The (internal! change?) launchpad list gets an email. This is described on the /Trunk page. |
This page describes the "master" branches for Launchpad development. Please ask for help immediately if you have any questions. |
Where's trunk?
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:
devel Where most development takes place (except anything that involves changing the database schema; see below).
db-devel Changes that modify the database schema get merged here first.
stable This is fed by regular merges from the devel branch, and is deployed to edge.launchpad.net daily.
db-stable This is fed by regular merges from the db-devel branch. It is deployed to staging.launchpad.net daily, and deployed to launchpad.net on each release.
In summary: db-stable is the post-test-run counterpart of db-devel, and stable is the post-test-run counterpart of devel, where "post-test-run" means that once code hits foo-devel it is only cleared into foo-stable if the buildbot test runner succeeds.
db-devel is also the default stacking branch for other Launchpad branches, as it usually has almost all of the revisions that are present in any of the four trunk branches.
If you want to know how all of this works behind the scenes, read Trunk/Glue (after reading the rest of this page).
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.)
Below, we break the process down a bit with a different diagramming approach. Here's what happens when you submit to devel:
Where are the expected potential problems in the process? Glad you asked!
It is also possible to submit directly to the db-devel branch.
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 deployment: 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:
Developers submit to devel and db-devel.
Buildbot tests the tip of db-devel, in addition to devel. If a db-devel change passes, it is pushed automatically to db-stable.
When changes are approved by buildbot to go from devel to stable, a script also generates a PQM request to merge stable with db-devel, sent as if it came from the Launchpad list. The Launchpad list will be informed of merge failures, and launchpad developers will collectively be responsible for correcting them. (TODO: is this some internal list? Hmmm.)
Staging runs db-stable; edge runs stable. We will deploy launchpad.net site from db-stable. (After a deployment, db-stable is manually pushed to devel and stable.)
When devel or db-devel get a test failure, we go into [testfix] mode for both branches. If only one branch is broken, a [testfix] to the broken branch that then makes the tests pass will reopen both branches for normal use.
Problems that can occur
The merge from stable to db-devel fails. That's a real risk but we expect it to be occur infrequently. When it does occur, the Launchpad list (TODO: which one?) will be emailed, and it is the collective responsibility of everyone to fix the problem, by manually submitting a branch to db-devel that includes the branch that failed to merge plus any necessary adjustments.
Where to Send Merge Requests
Merge requests that do any of the following should be sent via PQM to the db-devel branch:
- changes the database schema
depends on database schema change only in db-devel / db-stable
requires changes on machines other than edge
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 stable -> 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?
See also WorkingWithDbDevel.
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:
- I suggest creating an alias in bazaar.conf like:
dbsubmit = pqm-submit --submit-branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
Then the last line can be just this:
bzr dbsubmit -m '[r=so-and-so] improve frobnitz'
XXX: Shouldn't this be unnecessary if you have ~/.bazaar/locations.conf configured right?
FAQ
Can I land a testfix before buildbot has finished a test run that has failed or will fail?
Yes you can, and please do if appropriate, because this will mean that other developers will not encounter [testfix] mode at all.
If db-devel is broken, does that mean that devel is also in [testfix]? Why?
Yes, as mentioned before, there is a single [testfix] mode for PQM. That is because we regard this as a stop-the-line system breakage.
What happens if the automatic merge from stable to db-devel fails?
The (internal! change?) launchpad list gets an email. This is described on the /Trunk page.
