0.8 release plans

[Michael Ellerman]

Speeeeeed.

I realise performance tuning is pretty hard to do while things are
moving around so much, but if people are going to be using this
release in 12 months time it'd be nice if some attention was paid to
speed.

IMHO (on my 1.6GHz/1.5GB laptop) bzr is fine for use on trees of
bzr.dev size, and is snappy on smaller trees. So I think it compares
favourably with darcs on small trees, but on big (kernel size) trees
bzr is slow enough that you notice it, and eg. if you're doing a
status you'll probably want to go and check your mail while it runs.

FWIW that's still streets ahead of cvs/svn, but for some operations
git and hg are faster than bzr.

I'm _also_ pretty busy at the moment, but if people have ideas where
we can speed stuff up I'll try and find time to run tests on my bzr
kernel tree.

cheers

On 2/8/06, Martin Pool <mbp at sourcefrog.net> wrote:
> I'd like to sketch a map for an 0.8 release in the next few weeks.
>
> Ubuntu's Dapper release will ship with the version of bzr from March.
> Robert, James and I would like to make sure that some pending
> improvements on top of 0.7 can get into that release, implying an 0.8
> release in early March.  (This is not going too far out of our way,
> since we want to get towards 4-6 week releases anyhow.)  From this point
> on bzr is going to be more extensively used by Ubuntu and Canonical
> developers and so we would like data and code that depends on this
> release to be supported for a fair while (6-12 months).  API stability
> was previously discussed here and I think we have a good understanding
> of what can be done as far as deprecation and documentation -- it's not
> totally black and white.
>
> There is some scope for putting bugfixes into the dapper-updates channel
> if there are problems, but they really should be bugfixes not new
> features.
>
> Robert pointed out this morning that Baz suffered a bit from changing
> the default format, which in a distributed system tends to force
> everyone to upgrade.  To avoid that Robert and I and Canonical would
> like the format used by 0.8 to remain the default format for future
> releases, say through the following 12 months.  That doesn't mean there
> can't be new formats, or that they can't be recommended for particular
> situations.  It's hard to predict what developments we will see in the
> future, but this is the goal.
>
> These imply trying to integrate the features that majorly affect storage
> format or API before this release, and in particular those that enable
> later development.
>
> The major features still to land for this then are
>
>  * bzrdir refactoring (if more remains to be done?) - this allows
>    having directories which contain either branch, repo, or working
>    directory data, or any combination.  This enables checkouts,
>    shared storage, etc.
>
>  * tagging
>
>  * nested tree support (at least in data formats)
>
>  * changes to ignore handling
>
>  * VersionedFile
>
>  * new locking that's better across non-local transports
>
>  * working directory last-revision marker
>
>  * John's format-7 branch(?)
>
>  * (what else? please reply)
>
> Other things might be good to land as well; please reply and add them.
> TreeTransform perhaps doesn't relate to data stability but looks like a
> nice cleanup, for example.  I would like to hook up tests for PyCurl and
> get that in, and to change inventory and revision to Rio format to
> relax the ElementTree dependency.
>
> This sounds like a lot (and is a lot), but in many cases there are
> already good branches:
>
> The timeline should be approximately:
>
>    1 Mar    make 0.8rc1 release candidate, start 0.8-fixes branch
>   10 Mar    0.8 final?
>
> Robert and I will be making a push to get the existing code on this
> updated (if necessary), reviewed and integrated.  (Which is kind of bad
> timing for me because I'm trying to move to Sydney at the same time, but
> we'll manage.)
>
> What do you think, sirs?
>
> --
> Martin
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFD6VOIPGPKP6Cz6IsRAsVgAKC0iKleuRVYVuTq9wQogumTP1C/zACgnTN5
> gjynIsvr4hjiZETaNxQncUo=
> =/Pjx
> -----END PGP SIGNATURE-----
>
>
>