New 1.14 RC date?

[Robert Collins]

On Thu, 2009-04-02 at 12:41 +1100, Ben Finney wrote:
> 
> 
> An off-hand remark from one of the Bazaar developers led to me using a
> not-ready-for-release format that was, nevertheless, in the released
> Bazaar I was using. I was in need of solutions to try, and was
> confident that any code in the release was only there because it had
> already survived the testing of those who wanted to test development
> versions.

I believe you used a rich root format, *not* a development format; or if
it was a development format, it was the rich root flavourness that
caused problems.

> That confidence was betrayed, and I'm still enduring the fallout from
> incompatible repository formats. I'm firmly of the opinion that the
> divide between release and development is there to stop *exactly* this
> kind of leakage: I was not at all willing to be a guinea pig for
> development code, and was using the released version precisely so that
> I didn't have to be aware of what bits of it should not be used.

You're enduring the fallout of rich roots, its a serious problem and the
relevance from it to this discussion is that rich roots were added to
bzr *before* we'd learnt about making in-development features much more
clearly 'development'. 

In fact, with brisbane-core we're hoping to eliminate the headaches by
migrating once and for all to a rich root format for everything, *when*
we mark brisbane-core as completely finished.

> To me, the prevention of those kinds of issue is clear: if people
> *want* to test a feature still in development, they should explicitly
> choose the development code. Code that's not ready for release should
> not be in the release *at all*, otherwise the entire point of a
> distinction between “released” versus “not yet released” is
> undermined.

It sounds like you're trying to help other users avoid running into
similar problems, and thats good. However as I point out above there are
two rather different issues here.

We have brisbane core which is solid code that may still have rough
edges, but isn't radically altering the data model or other high level
aspects of bzr. We need a vehicle to get widespread testing, and we've
found that requiring users to get the code from another branch or a
plugin is a sufficiently high barrier that more hand holding and effort
is required.

And we have rich roots, which adding brisbane core to bzr.dev today will
neither make better nor worse; but which failing to get a reasonable
amount of informed testing on will impede a successful promotion to
release-quality, and thats why we want to get this into the core.

I think the crux of this discussion may hinge on the definition of
release quality; and also perhaps on audiences. For various reasons we
have only one effective channel for getting code to users - releases.
Plugins may or may not be packaged. Such plugins, particularly plugins
with C dependencies [for performance] are less likely to be packaged and
thus harder for people with very large trees to get hold of and test.
The simple fact that we don't expect dog eating is a pretty large
statement of confidence. The sorts of rough edges that remain are "whats
the best way to sort the data", "how can we make conversions faster",
"how big should internal know X be".

-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/20090402/f10135d0/attachment-0001.pgp