Sprint summary/impressions?

[Robert Collins]

I thought the sprint went really well, and Alexanders summary is great.

There are some things I'd like to expand on :)

The win32 support on babune made great progress - we tracked down two
root causes - testtools was known to be outputting multiple
exceptions, but because win32 was failing, these made it look like the
whole thing had blown up and interfered with analysis; secondly, the
bug that Martin[gz] had already filed about tracebacks not formatting
as safely as needed was in fact causing many failures to be hard to
diagnose, because the real error is lost. He's put a patch up for
testtools that I'll review today I hope.

Versioned Properties and Nested Trees- these were talked about a few
times and from a few angles. The one I remember most strongly was the
idea that we should fix the core to allow both of these things to be
done *well* as plugins:- currently they are high risk experiments, and
thats been making us do design up front and be insecure about stuff.
The subprojects plugin, for instance, has been successful, but is
limited by bzr's api/core in some places. For instance, the post-push
hook wasn't supplying the 'force' parameter, so pushing of sub
projects can't tell if it should or shouldn't. Versioned properties
should be able to work with .bzrmeta/versionedproperties (for a plugin
called bzr-versionedproperties) to gather data about how its used and
what things we'd need an in-core implementation to do. And making sure
its possible to do it as a plugin means that folk can experiment and
find the semantics they need, without worrying about addressing all
needs for core (e.g. scalability) up front.

We also talked about reducing the global variables we have - and we have a few:
 - logging
 - hooks
 - ui_factory (which is no longer a factory)
 - smart server jail
A context object was put forward by me as a possible way to do this;
it would need to be tasteful, tested and not involve changing every
single API :). Marius expressed some interest in doing this - I look
forward to patches :) One particular part of the discussion was about
transitioning - if we have a default for these globals which is
no-worse than they are today (e.g. the default logs to where we do
today), then parts of the codebase we haven't gotten to yet, will
behave as they do today. The default for different things might be
different - e.g. the default ui factory might be SilentUIFactory.

Oh, and must not forget - we made push 10% faster locally. We need to
make it faster though, for full history pushes we're wallowing at the
moment.

-Rob