Recipes vs. Looms vs. pipelines
Aaron Bentley
aaron at canonical.com
Wed Dec 16 18:28:13 GMT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Arbash Meinel wrote:
> Aaron Bentley wrote:
> 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.
With looms, this works because the loom thread is a mirror of upstream.
The analogue with pipeline is to have a mirror of upstream in the pipeline.
> Going further, that also is a fairly significant difference between the
> *goals* of looms versus pipelines.
You didn't actually name differences in the goals, so it's hard to
respond to this.
> 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.)
With looms, you get a huge proliferation of threads. I think the only
real difference is that threads tend to be less visible than branches.
> Which (IMO) is something that pushes for having a real DAG in the loom
> state, rather than just a stack model.
> You'd run into the same issue with pipelines, since they are also a
> simple stack.
This is something that's been requested for pipelines as well. I have
similar concerns to the ones James expressed about a DAG being harder to
work with, but I'm still considering it.
> 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'm not sure what you mean here.
> 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.)
+1 on better cherrypicking support.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkspJrkACgkQ0F+nu1YWqI1NKwCeKA78u8SYEwnWXy0WhDdJIEWf
nvAAn0zWvmkTUWGXOwcz5/2lQENbi/WM
=B5Us
-----END PGP SIGNATURE-----
More information about the ubuntu-distributed-devel
mailing list