Plans for post 0.8

[Martin Pool]

On 10 May 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 0.8 includes (at least) two major changes to bzr: knits and
> repository/checkout workflow.  Feel like real progress toward where we
> want to be.
> 
> I thought it would be useful to list some of the other major projects
> that I can see us working on to improve bzr.

That's a very good list; I'll add a couple more.

> History Horizons
> ================
> Currently, bzr always makes a full copy of revision history when
> branching.  This allows some convenient assumptions for bzr developers,
> but is not especially useful for users.  The older a revision is, the
> less likely it is to be useful.  And in fact, annotation-based merges
> like KnitMerge do not require the basis version to be stored, so perhaps
> we can get rid of the need for old revisions in merging.

Good point.

General performance work
------------------------

There are likely many places where we are slow not for any good reason
or because of underlying design issues, but just accidentally, because
we haven't checked very much.  We should set up a reproducible benchmark
that exercises key features and run it regularly, watching for
regressions; and also profile particular operations.

> Async/batched operation
> =======================
> We can and should optimize knits, and that could make branching take
> about 4 minutes.  (See below.)  But to get speeds faster than 4 minutes
> without a smart server, we'd need eliminate latency through async and/or
> pipelining.  Each of the core developers has had a go at this, so
> clearly we all want it.  We just disagree on the right approach.

My idea here is to have a more concerted go at using Twisted in a
way that we're all happy with.  I'm not sure it will work well, but I
want to either get it in or positively eliminate it.

Documentation
-------------

There is some, but it's not organized well and doesn't cover all
features; it also has too much of a mix of general concepts, advocacy,
developer documents, switching-from-cvs, and tutorial.  The most
important is a tutorial/user manual; we should focus on that.

-- 
Martin