Ubuntu/bzr stories update

[Andrew Bennetts]

[moving discussion to the public bazaar list]

Vincent Ladeuil wrote:
> Just a quick comment to ensure we don't focus on solutions too
> early.
[...]
> 
>     Andrew>  * The key feature requirement, and design question,
>     Andrew>  is bzr's support for a loom-like structure for
>     Andrew>  packages.
> 
> 
> I agree that this is one of the most important design decision
> for the Ubuntu Distributed Development project.
> 
> I don't think a loom is enough though.

I agree.  I didn't mean “loom-like” to necessarily mean looms.  What I
meant to convey was that that there are multiple branch (or branch-like)
pieces in a package, and developers want to be able to operate on the
combination of these as a coherent whole (as well as individually,
perhaps).

> There are at least three kind of important branches:
> 
> - the upstream ones,
> - the debian ones,
> - the ubuntu ones.

Right.  And the way developers typically think about packages is as some
sort of collection of patches on top of an upstream, so potentially the
“ubuntu one” is a loom (or other object that can track multiple
more-or-less independent changes), and that is assembled into a source
package tree using bzr-builder or nested trees or something.

> It's true that an Ubuntu dev will be mainly interested (probably)
> by a loom in the end, but the above branches are still important
> and interacting with them may not be trivial with just a loom
> (not to mention looms can be scary for newcomers)

My feeling is that:

 a) the more ordinary the underlying bzr representation is, the better
    (for saner development and debugging of tools, etc), but also...
 b) most of the time the exact details of how bzr + plugins are tracking
    this stuff is not important to the developers.

Developers think about source packages as “take an upstream version, add
some patches”, more or less.  That seems like a reasonable model to me,
and it would be a step backwards to make them have to add lots of bzr
details into the mix of concepts they need to have a thorough
understanding of.

I think they'd ideally be working with tools that support operations
that operate on the level of “use different upstream version”, “add a
patch”, “revise a patch”, “drop a patch”, “compare patch set in mine
with patch set from Debian”, etc.  If we make these things easier to do,
we're succeeding.  If the abstraction is very leaky and they keep having
to poke at e.g. bzr-builder recipes then I think bzr will be as much a
hindrance as a benefit.

> Upstream may or may not use bzr (or any DVCS tool), the wiki
> pages imply that the debian branches will not be available in a
> first step and James is working hard to populate the Ubuntu ones.

Yes, mapping or importing packages (for packages not maintained with bzr
in this way) in a useful way is going to be important.  The huge
diversity of packaging methodologies is going to be a real PITA here,
but at the least we should try to have an answer for packages that have
a set of distinct patches.

-Andrew.