launchpad development
Bind branches to product series
Status: Very rough draft. Please edit.
Blueprint: branch-product-series
Outline derived from David Allen's "Natural Planning Model". Not sure how useful the last two sections will be here. -- jml
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.
Actually, it's not precisely a spec. It's more of a document to focus discussion.
Purpose (Why are we even talking about this?)
- We are seriously thinking about making source package branches belong to distroseries, and we want there to be consistency between upstream and distro.
- 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.
Desired Outcome (What does wild success look like?)
Bazaar interactions
Fetch trunk:
$ bzr branch lp:python trunk
Push up a personal branch:
$ bzr push lp:~jml/python/2.6/fix-something
Fetch a branch of something:
$ bzr branch lp:~jml/python/3.0/another-patch
Brainstorm (Any ideas at all)
There are two relationships between branch and series. The first is the existing relationship, where a branch essentially is a series. This is stored in the ProductSeries.user_branch column. The second is that when a branch is intended for a series. We already have something of that second relationship in merge proposals. Perhaps we can make a bigger deal out of that?
Organize (Turn this into a real spec)
