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

[Robert Collins]

On Mon, 2009-04-06 at 12:47 +1000, Ian Clatworthy wrote:


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

development5 has never existed in trunk, I think the potential for
confusion existed solely amongst developers working on brisbane-core,
not for general users.

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

There are two issues:
 - serial or release number
 - having an alias.

I don't care strongly either way about the use of an alias. The
rationale is written down, and if its wrong it's wrong.

The reason for using a serial is twofold. One is that the next release
number isn't always known and development formats are meant to be
lightweight. Secondly there isn't a strong correlation with a release
amongst development formats. Once the format lands in bzr.dev its frozen
and we have in the past, and I'm sure will in the future, need to make
multiple revisions to a development format within one release - and this
means that labelling them with release numbers is problematic and
increases the cost. Finally, I don't think that having a correlation
with a release is beneficial for development formats. Unless we do a new
one on every single release the N and M used to identify a development
format will only coincidentally correspond to a users version of bzr,
and unless all the elements of a development format go into the next
production format [which hasn't happened in this release, and this isn't
a guarantee] suggesting to users that '1.14-development is worse than
1.15' is misleading and false.

I *really* want us to keep the timelines separate, because we are
treating them separately in our development process and tying them
together will lead to a different sort of confusion than is currently
creating by using a different timeline, and I think a worse sort of
confusion.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090406/11a42748/attachment.pgp