Recipes vs. Looms vs. pipelines

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
...

>> Looms are currently available in the bzr-loom plugin, but it
>> is generally agreed that this needs some polish to be really
>> usable.
> 
> bzr-pipeline is definitely already usable.  I use it daily, and it has
> other fans, like rockstar and thumper.  It is also under active development.
> 
>> Looms also allow for versioning at the loom level, as well
>> as at the revision level. This means that it is possible
>> to merge a loom as a whole, including operations that
>> add and delete threads. This is crucial to building a
>> packaging system on top of them.
> 
> These features are enbryonic in loom, and they could be added to
> bzr-pipeline.
> 
> Aaron

I would mention that for packaging, I think you really do want to have
'upstream' as the first thread, which doesn't work with the pipeline
model, since a given branch can only participate in one pipeline.

Going further, that also is a fairly significant difference between the
*goals* of looms versus pipelines. Namely, I think "recipes" wants to be
able to share a branch as part of the build process. Otherwise you end
up with a huge proliferation of branches. (I want to build Foo with all
these Ubuntu patches, and just add my one patch at the end.)


Which (IMO) is something that pushes for having a real DAG in the loom
state, rather than just a stack model. As it means you can push *just
this thread* into upstream, and have them merge it, without them having
to merge all of your other changes. Otherwise the loom is just there to
help you develop the patch. And then you throw away all the history once
the patch gets applied to upstream.

You'd run into the same issue with pipelines, since they are also a
simple stack.

Thinking about the 'ideal' workflow, I don't think having a tool that
lets you get to the point where you can create a nice patch and apply
it, is the ideal end goal of packaging and UDD.

I suppose the other alternative is to do better cherrypicking support in
bzr, though they are a bit orthogonal. (You'll always want better
cherrypicking support, as you won't always have factored everything out
cleanly at first, etc.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksnxEYACgkQJdeBCYSNAAP/WwCgp39aN7bi3oSbfobEPR/KJwNl
XP0AnjDDNWwt0eVV1JEWI64QxGWQXYQi
=dBBa
-----END PGP SIGNATURE-----