Recipes vs. Looms

[Barry Warsaw]

On Dec 14, 2009, at 05:59 PM, James Westby wrote:

>During UDS conversations with various people started to condense some
>thoughts that had been floating in my head for a while around recipes
>and looms: the difference, similarities, overlap and clashes that they
>have. This is another long mail. I apologise for that now, but this is
>a deep topic, and I think it warrants the length, as it is fundamental
>to the things that we plan to do.

This does dovetail nicely with my "First impressions" thread.  I wasn't aware
of the recipes model, have never used it, and don't have a visceral sense of
the pros and cons.

I really like the looms approach though and am getting a better understanding
of how package development would work using it.  What I really like is that I
can basically use the same tools I use to develop the upstream source code, to
develop the Ubuntu packages based on that upstream.  I have to learn some
things, but they are the things that are most relevant to Ubuntu packaging.

>There are discussions about whether the "stack" model presented
>by loom is the best, as it entagles threads that don't necessarily
>have a dependency. There are alternative models proposed, including
>a full DAG as implemented by TopGit. My fear is that they are
>too complicated for people to easily grasp, and that they are
>not the best way to solve the problems they aim to.

I can see this.  Even with "normal" software development, the stacked nature
of looms (and pipes TBH) is both a pro and a con.  Usually it works great, but
sometimes it's not a perfect fit and then it can get painful to unwind
things.  But I'm not sure the extra complexity of a DAG is worth it.

>Recipes also require a proliferation of branches. To add
>a patch you would have to create a new branch, push it to
>LP, add it to the recipe, and then pull it in. While we
>can script this, it is also fragile, and perhaps not very
>elegant.

This to me is the biggest concern with the recipes approach.  I want to be
able to work completely off the grid for as long as possible.  I want to be
able to do everything locally up until the time I need to share code with
other people (for review, sponsorship, merging).

>Looms on the other hand currently have no parent pointers
>per-thread. This makes it impossible to do a full update
>without extra information. At the least we need to be able
>to pull in the upstream changes to the bottom thread for
>daily builds, but recipes allow you to pull in changes to
>all the other threads at the same time.

I don't fully understand, but when I've done Launchpad branches using threads,
the bottom thread always points to my local copy of trunk.  Thus, if I update
my (outside-the-loom) trunk branch, then down-thread to the bottom, bzr pull,
then bzr up-thread (I think --auto is the default), I'll have merged in the
new trunk to all my threads.

>Given that recipes don't appear to work very well at all for
>normal Ubuntu development (add a patch type work), and looms
>could be modified to support the daily builds type work
>(update all the threads from their parents and build the
>result), it seems to me as though we should perhaps be looking
>to modify looms, rather than develop a whole new system.

+1, modulo my total ignorance of recipes. ;)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20091214/fb2d66ed/attachment.pgp