nested trees design-approach : composite trees vs iter_changes

[Martin Pool]

2009/5/6 Robert Collins <robert.collins at canonical.com>:
> On Tue, 2009-05-05 at 10:19 -0400, Aaron Bentley wrote:
>
>> I've heard your objections.  They don't resonate with me.  You haven't
>> vetoed, so I believed that you would let me get on with it, even though
>> it's not your preferred approach.
>>
>> Instead, you have been undermining me.  I don't like being vetoed, but
>> it is better than being undermined.  It is at least direct.  It
>> demonstrates that your objections are strong enough that you're willing
>> to derail the current development over them, and that's important data.
>
> Concerns that aren't addressed rarely just go away; trying to get it
> discussed wasn't intended to be undermining, but an attempt to get it
> discussed!

I'd like a clear enhancement-proposal document describing the user
cases for nested trees, the formats and the api changes that enable
them, before we go any further with these code reviews or merging
them.

At the moment there are wiki pages that briefly discuss it but they're
pretty small.  Most of the issues coming up here are really design
issues, but they're not discussed there at all.  Doing it at the patch
review level is inefficient and I believe that's adding to the mutual
frustration.

This document needs to talk, down to a ready-to-code level, about the
UI changes, the formats, and the API changes.

One example is whether commands should descend into subtrees by
default and how that should be controlled.  We've talked about cases
where you would or wouldn't want it.  You can get this data from
looking at the patches to individual commands but that's not an
approach that lets us have the high level discussion and it doesn't
ensure the interface will be consistent and clear across them.

This doesn't mean going back to square one, though it does mean
describing it from the ground up.  I suppose much of the design is in
Aaron's head, and some has been talked about previously in various
places.  It may seem like that will just reopen a lot of discussion
you'd hope to avoid, but doing that discussion around one coherent
document will be faster than the kind of block-to-block fighting we're
in here.

Ian agrees this would be useful and said he'd start drafting one based
on his understanding of the patches he's read so far.  Aaron, I would
ask you to pick it up from Ian and I hope it will be an easier way
forward for this feature that we all want to see finished.  Put in
what you can think of, but post it sooner rather than later so others
can add data or ask for more information.

-- 
Martin <http://launchpad.net/~mbp/>