Ubuntu/bzr stories update

[Vincent Ladeuil]

>>>>> "Andrew" == Andrew Bennetts <andrew.bennetts at canonical.com> writes:

    Andrew> I agree.  I didn't mean “loom-like” to necessarily
    Andrew> mean looms.

Good.

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

    Andrew> Right.

Good.

<snip/>

    >> 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)

    Andrew> My feeling is that:

    Andrew>  a) the more ordinary the underlying bzr
    Andrew>  representation is, the better (for saner development
    Andrew>  and debugging of tools, etc), but also...

+1

    Andrew>  b) most of the time the exact details of how bzr +
    Andrew>  plugins are tracking this stuff is not important to
    Andrew>  the developers.

+1

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

Full agreement.

    >> 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.

    Andrew> Yes, mapping or importing packages (for packages not
    Andrew> maintained with bzr in this way) in a useful way is
    Andrew> going to be important.

I have doubts about that, I think it should possible have a
working solution even if the upstream branches are not available.

Of course the available history will be poorer in that case, but
we can still provide a working solution.

    Andrew> The huge diversity of packaging methodologies is
    Andrew> going to be a real PITA here, but at the least we
    Andrew> should try to have an answer for packages that have a
    Andrew> set of distinct patches.

Yes, that's the important point.

     Vincent