New 1.14 RC date?

[Robert Collins]

On Thu, 2009-04-02 at 08:29 +1100, Ben Finney wrote:
> Vincent Ladeuil <v.ladeuil+lp at free.fr> writes:
> 
> > People are aware that this is a development format and that we will
> > be even more responsive than usual to any problem they may encounter
> > using it.
> > 
> > I even suspect some of them may have already started playing with it
> > but wait for a more official version before giving feedback.
> 
> I don't agree with this at all. What ground do you have for stating
> that “people are aware that this is a development format”? Was that
> also true of previous development formats that appeared in releases,
> and if not, what has changed since then?

We have a number of formats called 'development-X' which are intended to
let early adopters test beta quality code. We did this for the B+Tree
index, and current testers of the views and filtering tree code are
doing it as well. The way it works is that a user wanting early access
can just grab a current build (e.g. bzr 1.14 release once it happens :))
and then init --development, and they get the current beta format.

We document (e.g.
http://doc.bazaar-vcs.org/bzr.1.13/developers/development-repo.html)
this so I'm only going to hit the high points here.

Development formats are:
 - beta or better quality
 - supported [but for a limited time]
 - guaranteed to have an upgrade path to a production quality format

These are the criteria we observed people asking about/holding back from
testing or using new code in the past.

> Those who are waiting for a “more official” version are, IME,
> waiting for a “more reliable” version. Such people are deliberately
> *not* running a development version so they can be sure that
> everything they're running is blessed as “release quality”. Pushing
> a still-needs-feedback format into a release in an attempt to get it
> used by such users has *not* worked well in the past, and I see no
> reason why it would work any better this time.

This is a strawman though, Vincent didn't suggest that users wanting
'release quality' formats would help test. And we have observed that
asking people to run a different format can be very successful [for
instance, a number of MySQL developers tested the B+Tree based format
while it was in beta].

> If you want to attract more testing and feedback for the format, that
> is a signal that it needs to stay *out* of the release, IMO, and that
> instead you should be attracting the type of users who *want* to do
> such testing of in-development functionality. An official release is
> not the place to seek such users.

We have a period during development of features during which we only
seek testers that can deal with a rapidly moving and potentially buggy
codepaths; and we've been receiving regular reports of issues and
concerns for the brisbane core format from such testers. I think we're
now beyond this and ready to start getting more widespread testing. The
disk format has stabilised, and we anticipate only tuning and
programming API changes from here on in. That is we are ready to move
from alpha "if it eats your dog you get sympathy" to beta "if it eats
your dog we'll sew him back together for you".

I think that we should finish the items on
http://bazaar-vcs.org/Roadmap/BrisbaneCore listed for inclusion as a
beta format. Which is basically just code review and the licencing ACK
for for using xdiff3 as the CHK page sizes have been settled to the best
of my knowledge.

If this is < 3 days {andrew and I are working on the streaming inventory
fetch which is part of the beta to make networking sensible} then asking
for a delay for the RC makes sense to me. If its feels like its more,
then we'll probably slip anyway.

+1 for a delay from me.

-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/55c4ca1c/attachment.pgp