bzr usage for package branches
We currently maintain most Ubuntu Desktop packages in bzr branches and
use bzr-builddeb in merge mode [1] with packaging stored in
lp:~ubuntu-desktop/package_name/ubuntu. The other option was to use
normal mode [2], but this was not chosen at the time due to the size of
checkouts.
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
accident
- 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
broken (repeatedly).
- 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 [3]
--Robert
[1] http://
[2] http://
[3] https:/
Blueprint information
- Status:
- Complete
- Approver:
- Martin Pitt
- Priority:
- High
- Drafter:
- Robert Ancell
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- Accepted for oneiric
- Implementation:
-
Informational
- Milestone target:
- None
- Started by
- Completed by
- Martin Pitt
Whiteboard
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.
