bzr 2.1 retrospective

[Andrew Bennetts]

Pardon the late reply.  I basically agree with the recommendations in
Martin's mail.  Here's a brief comment:

Martin Pool wrote:
[...]
> * change: pick one or two focus features for 2.2?

Picking focus features seems to work best when the focus is very clear.
For 2.0 we had the goal of “finish 2a”, with a clear list of bugs that
had to be resolved before we could call that task done, and that worked
well for us.  The goal — and the path to that goal — was extremely
clear.

Here's a strawman idea: what about having “focus bug tags” rather than
“focus features”?  We are mostly good at having reasonable bug reports
with clear criteria for being fixed.  Whereas a hypothetical feature
like “better performance” sounds attractive but doesn't readily
translate into concrete tasks.

[...]
> * change: Plugins must have bugfixes only, relative to the version
> shipped in rc1.
> * change: Clearer reminders to plugin authors that this deadline is
> coming up, and of what it means to them.
> * change: Insist on zero changes between the last rc and the final
> release?  This may be waste though; making the release takes some work
[...]
> * affirmed: API stability by code branch
> * affirmed: delete crufty code!

We still need to do better on this: what to do to help plugins keep up
with changes in bzr (and help bzr know which changes are troubling
plugins well before the final release).  I don't really have anything to
add to the threads already started on this topic, although for plugins
with good test suites monitoring them with babune might help a lot.

-Andrew.