bzr 2.1 retrospective

[Martin Pool]

On 25 February 2010 18:14, Andrew Bennetts
<andrew.bennetts at canonical.com> wrote:
> 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.

That's a good idea.

I'd suggest the focus for 2.2 be the 'merge' and 'conflicts' tags, so
we can build on what Vincent has started there.  This will help many
people.

>
> [...]
>> * 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.

Actually there were some interesting ideas on irc today:

* get plugins to do more like bzrtools and fail only when you try to use them
* have a broken-windows branch, writable by ~bzr-core, for each plugin
to keep it passing selftest under bzr tip
* have a 'recommended version' as distinct from 'requires version',
and if bzr crashes point out any plugins that may be out of date

-- 
Martin <http://launchpad.net/~mbp/>