bzr usage for package branches
We currently maintain most Ubuntu Desktop packages in bzr branches and
use bzr-builddeb in merge mode  with packaging stored in
lp:~ubuntu-desktop/package_name/ubuntu. The other option was to use
normal mode , but this was not chosen at the time due to the size of
My experience since moving to bzr branches:
- Much, much faster updating of packages
- Branching packages is possible (e.g. working in a PPA)
- Patches are a little bit harder to do, as the branch doesn't contain
the files from the source tarball
- People are often ignoring the branches and uploading directly (or
forgetting do a bzr push) which means changes are sometimes dropped by
- People often do merge requests to lp:ubuntu/package_name, even when
there is a packaging branch
So, I propose that we move all the current packaging branches to using
lp:ubuntu/package_name branches. We have a few branches using this mode
and have had good success with them.
Some issues that will remain:
- It is possible to screw up the branches so that bzr merge-package
throws a confusing error (I keep doing it). Perhaps we need some hooks
in bzr to stop this from occurring. If it can be broken, it will be
- Branches with a lot of history take a lot of time/bandwidth to check
out. This adds a barrier to contributors, but is something that bzr
hopefully will solve in the future 
pitti, 2011-05-23: Added to tomorrow's desktop team meeting agenda.
From my POV I'd like to continue to use the ~ubuntu-desktop debian/ only branches. The main advantage of UDD branches are that they keep themselves synced to the archive, but otherwise they also require a more complicated workflow (see how often people get merge-upstream wrong) and fail to address *any* of the actual problems that the older custom branches have:
- UDD branches are not derived from upstream trunks, so you can't cherrypick patches or merge upstream to new versions. Neither are the debian-only branches, but we do have custom branches which are derived from trunks on Launchpad. We certainly shouldn't give up the latter.
- UDD branches still use plain text file patches for source modifications, instead of proper looms/threads.
- UDD branches have patches applied inline, which is seriously broken
- Creating new UDD branches (e. g. for a new project or the first SRU after release) is higher black arts (if it's possible at all, I don't know). It's straightforward for custom branches.
- They also need quite a lot more time for checking out and uploading, but that's only secondary.