Fwd: Ubuntu/bzr stories update

[James Westby]

On Tue Nov 03 12:58:47 +0000 2009 Martin Pool wrote:
> Briefly, a source package isn't cleanly represented with a single regular bzr
> branch. There are clear notions of “upstream” and “collection of
> changes to
> that upstream”. The NoMoreSourcePackages and DistributedDevelopment wiki
> pages
> mention this, but avoid going into much detail about exactly how this should
> work in Bazaar. An obvious possibility is something very much like a loom,
> where the base thread is the upstream version, and then each patch added to the
> package is thread on top of that (including a patch to add the debian/ directory
> with the packaging rules).

Debian have just started accepting a new source format, which could be analogous
to this, though there are a few more wrinkles. It's not exactly clear how this
will be used yet, but given that it includes a patch system in the format it
gives some hope that we can have an easier time of manipulating patches.

> 1. Mini-grumpy
> --------------
> 
> This isn't a story, at least not in the same way as the others — but Canonical
> is keen to do this because it enables stuff that isn't possible now.  James
> says
> that nested trees would be helpful for this (to assemble packaging branches and
> upstream trunks into one tree? James, care to elaborate on this?).

It would allow us to unify bzr-builder and bzr-builddeb to some extent. The former
can do a "nest" operation, that it can't currently represent in bzr for the latter
to work with. There could be various ways around this, but solving it in a clean
elegant way would be good, and give much more potential for interesting uses. In
addition nested trees have value on their own.

> 3. Compare packages
> -------------------
> 
> Having the diff is the main thing.
> 
> A neat report of patches added/removed/changed would be nice, not vital.
> 
> Simple “bzr merge” already found to be inadequate, there's some ad hoc
> smarter
> operations in bzr-builddeb now.

I explained that this is because we are treating a pair of branches as one,
but we consider some of the changes to be trusted. We therefore need a more
specialised merge process in some cases in order to present the developer with
what they want to see.

This is currently implemented as "bzr merge-package", but having "bzr merge"
do the wrong thing is bad, and I am desperate to fix that.

Thanks,

James