New 1.14 RC date?

[Andrew Bennetts]

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

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

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
   out.
 * 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.)

-Andrew.