Recipes vs. Looms

[John Arbash Meinel]

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

James Westby wrote:
> On Mon Dec 14 21:39:52 +0000 2009 John Arbash Meinel wrote:
>>> Looms are also currently missing a way to do the "nest".
>>> While this may be just a requirement to have nested trees
>>> in core, there may need to be changes I am not considering.
>>>
>> This isn't entirely true. While there isn't a 'nest' command from looms,
>> if you create a thread, then do whatever operation necessary to nest
>> (bzr merge-into, bzr join --by-value, bzr join --by-reference, etc),
>> then the loom should be able to represent it just fine. going up-thread
>> will add the nested directory, going down thread would remove it.
> 
> Good to know.
> 
> I guess my argument is just that nested trees in core aren't ready for
> production use in all these configurations yet.

Nested by value works pretty well, and I've used it several times.
(Merging the upstream code puts it into the subdirectory, etc.)

The main thing that you don't get with nested-by-value is that
committing a change in just the subdir can be easily merged  back into
upstream. (You can merge, but have to cherrypick, otherwise you get the
rest of the project.)


> 
>> I think the two systems do have a significant overlap. Recipes are
>> slightly easier to share, as their state is fairly well defined and
>> small in scope. Looms *do* have a shareable state, but it isn't quite as
>> simple as emailing a text file to someone. (Note, though, that if Merge
>> directives are taught about loom information, you could potentially send
>> a MD to someone which would build out the loom state.)
> 
> The issue with *just* emailing someone the recipe file is that currently
> they will end up with a different revision history in the final tree. Perhaps
> this is a mistake, but it means that just the text file isn't currently
> good enough for collaboration where this matters.
> 

How so? I thought recipes were meant to build the working tree, and not
actually commit any data. Obviously I may be mistaken in what recipes
actually include.

>> I get the feeling that doing your development in looms would be slightly
>> better. create-thread, hack, up-thread, and your changes are brought
>> into the integration thread. Versus anything that has to round-trip
>> through launchpad because you really want to have the official branch
>> locations in the recipe.
> 
> I agree.
> 
>> Recipes *might* end up at the same level as debian patch systems. You do
>> all your work in the actual working dir, and then you generate X and
>> revert everything you've done to actually get the package built. (X
>> being a 'diff' in debian patch systems, being a new branch on launchpad
>> in recipes.)
> 
> That's true. I think experience tells us that this isn't necessarily
> a great way to work. There are some benefits, but those aren't a
> requirement of the "generate, revert" type workflow in my eyes.

I think it would be a reasonable compatibility thing to be able to
export the first N threads of your loom into a debian + patches tree. It
is quite unclear to me whether this should be a thread above or below
the actual threads that produced these changes. (I would probably say
above, mostly because I think 'debian/' should be introduced above the
content changes...)

> 
>>> 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.
>>>
>> If you make sure the "easy is easy and the hard is possible" it might be
>> fine. With a decent visualization of the threads and their dependencies,
>> it does seem a fair amount more powerful. Mostly in that stuff like
>> "up-thread --auto" wouldn't have to merge everything into everything. It
>> would also allow for "bzr qlog" at the top thread to be a bit more
>> obvious as to how the development was meant to be perceived.
> 
> That is all true. The "decent visualization" is a bit beyond us right
> now I think. The main issue in my eyes is that "bzr branch; bzr <something>;
> hack; commit; bzr <something else>; build" gets more complicated with
> a full DAG. You would have to explain how to decide how you want <something>
> to work, how to work out if it is dependent on any of the other threads,
> etc.
> 
> Thanks,
> 
> James

bzr create-thread --based-on X

And the default of --based-on is the current thread. Presumably all
threads would be --based-on at least 'upstream'. I guess it would also
allow being supplied multiple times for the thread that brings together
the previous threads.

I think the bigger issue is that 'bzr up-thread' gets a lot more
complex. Given that up-thread to the bring-together thread potentially
issues several merge + commit statements. (At least several merges, we
could octopus merge it if we wanted.)

At least it would have all the information of what branches it would
need to merge in its DAG info.

You would probably need to add the ability to add and break links. "bzr
thread-dependencies, bzr remove-thread-dependency, bzr
add-thread-dependency, etc.)

It doesn't seem terrible. Though there is always the "one more layer of
abstraction" that ends up making something hard to work with.

John
=:->



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

iEYEARECAAYFAksmwHwACgkQJdeBCYSNAAOCAgCgrRsRTN4nf4cAfTNdpgEORyc4
1psAn1zYakqjie/rid1cqdXcJn63+hEl
=Xq5R
-----END PGP SIGNATURE-----