landing brisbane-core Q: development5/6 vs gc-chk-* plan?

[Ian Clatworthy]

Robert Collins wrote:

> One. It will complicate people testing it because it will have the rich
> root transition built in (and possibly subtrees depending on Aaron's
> choice about how to handle this).

Sounds ok to me. I think this needs to be done in brisbane-core and
not as a side effect of merging the changes across though. If John
agrees, I'm assuming it's in his court to make this change when
he's ready?

Also, Aaron does seem to be making great progress on the nested trees
stuff. I suspect he's blocked on someone reviewing his CompositeTree
patch though. Is anyone reviewing this? If not, can someone volunteer
soon please so I don't get tempted to do it? :-) (Seriously, I need to
remain focussed on integrating brisbane-core.)

> The 5 is a serial on the development namespace, not on repo/tree/branch.
> We varied from this slightly for your wt5, and AFAICT it just added to
> the confusion.

I disagree. Had we used the development6 name instead of development-wt5,
there was potential confusion about it including all of the stuff in
development5, rather than just a WT tweak.

> I'd like to roll that naming change back and resume the
> normal sequence. To avoid confusion with --development-wt5 I think
> --development6-rich-root. (the -rich-root to make it clear to people
> that do consider trying this that we're not offering a 'plain' format).
> We should rename the --development alias to --development-rich-root at
> the same time.

Well --development-wt5 no longer exists - it's now 1.14. --development-wt6
exists as a placeholder for the filtered views tests but it's completely
hidden and will be removed as soon as the gc format lands. (The comments
immediately above the code registering the format explain this.)

I'm also against the ambiguity that --development causes. If we have
a development format in 1.14 and tweak it in 1.15, then I'd greatly
prefer it - though I know you disagree - if they were called
1.14-development and 1.15-development respectively. Given our policy
as for the lifetime of a development format, including the revision #
has the same benefits as Ubuntu's release numbering policy - the
end-of-life of 9.04 is easy to determine, as is the end-of-life for
1.15-development.

It also means users who are helping us test can clearly try both
when reporting issues, rather than having to use --development
sometimes, --developmentN and --developmentM other times, where
N amd M have no obvious correlation with a release.

My 2c,
Ian C.