bzr 1.14 release schedule and manager
mbp at canonical.com
Wed Mar 25 08:02:03 GMT 2009
2009/3/20 Martin Pool <mbp at canonical.com>:
> I'm really hoping that in this release we can land brisbane-core into
> bzr.dev, so that it stays in sync and so it'll be ready for early user
> testing. We're going to have to negotiate expectations there
> carefully so that we don't get repeats of bugs we already know about,
> waste user time, or spend a long time supporting them. But if we can
> get it in even as an alpha format with no guarantees it would be a
> good step forward.
We talked a bit about this on the phone the other day, so I thought I
would summarize here.
I'll also mention, by way of background, John's recent post
what's going on in this branch.
I think we should get it in to 1.14rc1 if at all reasonable.
By "at all reasonable" I mean not if it's going to break other formats
in function or speed, and not if it's going to mean dumping in code
that's not clean, reviewed and tested, and not if it's going to
possibly draw users into running code that's going to hurt them. But
for the next week and a half I'd like us to focus on clearing off
those issues so it can sensibly go in.
It looks like this format is going to give very good size and speed
numbers. If we're going to get it to be a default for a 2.0 in June,
I think we need to start committing to having it stable, and to start
explicitly saying no (or "not yet") to things that might be useful but
aren't needed to have a big improvement on 1.9, and merging it to
trunk makes a line in the sand in that regard. It should mean things
get through a solid review, they shouldn't regress or diverge in
future, and it gives external plugin maintainers and advanced users a
chance to start profiling it and checking compatibility.
It would be nice to improve the current-formats help, and other
aspects of format handling ui. Some of these bugs are pretty shallow
if someone wants to step and try. But I don't think they necessarily
block getting brisbane-core in bzr.dev: it can be a new type of alpha
format with less compatibility constraints than development formats if
that's what's needed, but I do feel we should make steps towards
having it further towards production.
More information about the bazaar