-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Bentley wrote: > 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.
AIUI, being able to share pipelines is not one of your goals. > >> 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. True, though this is significant in itself. (possibly solved by colocated branches, but visibility of branches is a genuine UI issue.) ... >> 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. Without a DAG, if you want out-of-order selection of changes, then you need cherrypicking. This is often done as a diff + patch. (Or bzr merge with a range, but that is effectively a slightly smarter diff + patch.) If we are discussing "what is an ideal tool to be building", creating something that makes it easier to create a patch file doesn't seem ideal. Creating something that makes it easier to get a change integrated into upstream, and then reflected back in your workspace seems a lot better statement. So having the stack broken, which allows upstream to 'bzr merge' just one thread/pipe/branch without getting the other unwanted changes, which then comes in through your upstream branch, and bubbles up naturally (without conflicting from duplicate changes, etc.) You can get close if we made cherrypicking really smart, but I'm not sure how smart you can make it, or really what that design looks like. A DAG based loom/pipeline is something relatively easy to articulate. As it is what I do today with a pure-branch based flow without the 'up-thread'/'pump' helpers. > >> 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 I find the biggest problem being defining what "better" really means. In terms of data representation, and actual effect. We can say "we should be able to do better than this", but the details are really quite difficult. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspTVQACgkQJdeBCYSNAANsMQCeKBHvJH8XjvoUlv5Und51c5eB 8xYAn0HlMqKazzdYCJ7US43G31dVUCG2 =FGP8 -----END PGP SIGNATURE----- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
