New 1.14 RC date?
andrew.bennetts at canonical.com
Fri Apr 3 00:16:46 BST 2009
Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
> > However, I don't think it should be left out merely because it is a
> > beta-quality format.
> "Beta-quality" is irrelevant. It's *just* *not* *ready*. That's why
> more time was requested, no?
“Ready” for what? There are multiple issues being discussed across this
thread, and they keep getting mixed up. Here are some different types of
ready that have come up:
1. I believe it's considered ready for more wide-spread feedback and testing.
2. What Ian expressed concern about in the message that started the thread
is that it might be ready to merge into bzr.dev without destabilising
3. There's also the debate about whether a beta format that is may change in
future and have some performance bugs is something that is ready to be
included in a release as a hidden-by-default format accessed via an option
called “--development” or similar.
4. Does the patch meet the project's various criteria to be merged
into trunk so it can be part of the next release (reviewed, doesn't break
test suite, core devs are happy with design, etc)? i.e. once we take
everything into account, is it ready land?
The part of my message you quoted was addressing that third kind of
readiness, so “beta-quality” is absolutely relevant to the point I was
I think when you say “*not* *ready*” you are talking about the fourth, which
is obviously important! But the fourth is a composite of smaller issues
like the third.
> IMHO, a scheduled release should be delayed only for a showstopper.
> Otherwise, *everything* is a potential showstopper.
I think you're agreeing vigorously with me on at least these two points:
* time-based releases shouldn't be delayed, so
* we should not land a patch that will jeopardise the chances of putting
out a solid release on time, even if we'd really like to get that new
code in the hands of more users.
What I'm also saying is that:
* maybe it isn't all that risky to land (because much of the code is
completely independent, and most of the integration points already exist
for other formats, and some of the changes are already in bzr.dev). If
it is too risky, then as I've said repeatedly I agree we should leave it
* the fact that the format it adds is only beta quality does *not*
disqualify this patch from landing in time for the release, because it
would be hidden-by-default yadda yadda. (But of course other issues
might still disqualify it, like destabilising fully-supported features.
Just not this issue IMO.)
More information about the bazaar