Recipes vs. Looms

[James Westby]

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.

> 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.

> 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.

> > 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