Bind branches to product series

Status: Very rough draft. Please edit.

Blueprint: branch-product-series

Currently, branches in upstream projects are bound primarily to that project and in general have no link to a product series. This specification discusses how Launchpad might work if all branches had an associated product series.

Rationale

• We are seriously thinking about making source package branches belong to distroseries, and we want there to be consistency between upstream and distro. See PackageBranches.

• Part of Launchpad's value comes from being a reliable reflection of activity. Binding branches to series might improve Launchpad's ability to show currently active branches.
• By binding all branches to users, we might encourage them to place a greater focus on regularly releasing software. (Not sure how this works, but it's been raised -- jml)
• It's complex, there are a lot of edge cases and it'll be a lot of work, so the discussion is worth writing down.

Principles (I'd let anyone take over this as long as they... )

• Smooth migration from current model.
• Add no overhead in starting new, small, projects.
• Make the concepts and user interface bleedingly obvious, particularly for CVS / SVN refugees.
• Keep consistency between distro and upstream.
• Break the work down into manageable chunks that each provide value to the end user.

Out of Scope

• Distribution branches.
• Stacking.
• Altering Bazaar's directory service features.
• Privacy
• Specific changes to code.
• Planning the implementation.

Stories

Doris the Python Hacker

Doris wants to get the latest Python source code sos he can see what makes tuples different from lists. She fetches the latest Python:

$ bzr branch lp:python
Fetching bzr+ssh://bazaar.launchpad.net/python...

• XXX: Maybe that should be bzr+ssh://bazaar.launchpad.net/~python-dev/python/3.0/trunk? -- jml

Doris notices that there's a terrible lack of unit tests for the unittest module and decides to write some:

$ bzr branch python tests-for-unittest

Eventually she finishes and pushes his branch up to Launchpad:

$ bzr push lp:~doris/python/tests-for-unittest
Pushing to bzr+ssh://bazaar.launchpad.net/~doris/python/+latest/tests-for-unittest...

• XXX: Maybe that should be bzr+ssh://bazaar.launchpad.net/~doris/python/3.0/tests-for-unittest? -- jml

Her branch is now available at:

• lp:~doris/python/3.0/tests-for-unittest
• lp:~doris/python/tests-for-unittest

Wouter the Bazaar developer

Wouter has been working on the Nested branches feature since bzr 1.2. He pushes every sporadically, but never really merges into trunk because he's afraid of reviews.

Wouter has always pushed and pulled from:

lp:~wouter/bzr/nested-branches

BUT, the following canonical URLs have been created:

• ~wouter/bzr/1.2/nested-branches
• ~wouter/bzr/1.3/nested-branches
• ~wouter/bzr/1.5/nested-branches
• ~wouter/bzr/1.6/nested-branches
• ~wouter/bzr/1.9/nested-branches

}}}

Bzr's version in Hardy is 1.3, and Wouter realizes that it has a critical bug which he had a fix at the time, so he wants to create a 1.3.1 release.

He now goes to Launchpad and finds his branch at the 1.3 release, and does:

$ bzr branch lp:~wouter/bzr/1.3/nested-branches

He fixes the critical bug and pushes it back up to Launchpad at lp:~wouter/bzr/1.3/nested-branches, coordinating with the Registry team to figure out exactly how it is that you do a point release anyway.

Comments

This leads to a profusion of branches, but if well-managed this is not a problem. First, the primary listings will be on (product, productseries), so at most one version of "nested branches" will appear. After all, the big idea with linking to productseries is to hide branches that are not a part of the current, interesting lines of development.

Ideally, there would be a page, say ~wouter/bzr/nested-branches or ~wouter/bzr/+all/nested-branches that linked to all the series branches where nested-branches occurred. (XXX - haven't thought about how to implement this, seems non-obvious - jml).

Releasing Bazaar

Bazaar releases every month. What happens is that the Release Manager (RM) at some point makes a branch of trunk (aka bzr.dev) that the release will ultimately be made from. A tarball is made from this branch and advertised as the release candidate. Meanwhile, Bazaar developers keep making branches from trunk. These branches are considered to be part of the next release.

If a problem is found in the release candidate, the fixing developer branches the release branch, makes his fix and merges it into the release branch.

Ultimately the release is made from the release branch. If a point release is required, further changes will be committed to the release branch and another release made from the branch.

The process

We don't have a branch called "bzr.dev". There is only the series branch for the 1.8 series, which is the current development focus:

• Series 1.8*
  • A BRANCH (accessible as lp:bzr and as lp:bzr/1.8)

(the "*" means that this is the development focus series)

Then, when the release candidate is being made, the RM hits a button that "clones" this line of development (and the associated Bazaar branch), with the option to make the new series the development focus.

• Series 1.9*
  • THE OLD BRANCH (accessible as lp:bzr and lp:bzr/1.9)
• Series 1.8
  • A NEW BRANCH (accessible as lp:bzr/1.8 and probably stacked on lp:bzr)

In many cases, the OLD and NEW branches would be identical. However it's possible that the RM might wish to designate a particular non-tip revision as the start of the 1.8 series.

Note that the canonical name of the series branch is /bzr/1.8. In this way, the main branch of a product series becomes like the official source package branch, described in PackageBranches.

Wouter & Jelmer

Wouter last pushed his nested-trees up to Launchpad during the 1.9 cycle. Since then, 1.9 has been released and the 1.10 series has been opened and is the development focus.

Jelmer decides to see what he can do to make nested trees happen. He branches from lp:~wouter/bzr/nested-trees and gets Bazaar's equivalent of a 404.

Notes

The "development focus" property is actually sticky on a branch. That is, ~bzr/bzr/bzr.dev is always the development focus. Given that our data model goes product -> anointed series -> anointed branch, this is a bit crap.

Within a line of development, there are two sorts of branches:

1. The branch that *is* the line of development (in some sense). This branch tends to be long-lived. This information is already stored in the database.
2. Branches that are *intended for* a specific landmark on a line of development (which could be the horizon). This branch tends to be short-lived. We kind of store this with merge proposals -- perhaps we can make a bigger deal out of that?

ACTION: Talk to MySQL about the productseries-branch thing. This affects all our users and we should get their input, but MySQL are perhaps one of the most active and major non-Canonical users.