The rough plan for landing brisbane-core

[Ian Clatworthy]

Robert created the 1.14 branch for Bob earlier today so
I've started the process of integrating the code from
brisbane-core into bzr.dev. I'm looking to do this in
2 stages:

1. cherrypick the stuff which falls out easily and
   can sensibly stand-alone - see today's set of patches

2. merge the remaining stuff - the "guts" - from
   brisbane-core so that history and annotations are retained.

For the first group of patches, I'm using annotate to find
out who made the changes and why. I'm then using the
--author option on commit to assign ownership. I certainly
don't want everyone thinking I wrote everything being
landed. :-) After the various patches in stage 1 have landed,
I'll merge bzr.dev into brisbane-core and confirm that just
the guts remains.

For the second stage, I/we will probably still break stuff up
into pieces for the purposes of review. But the goal is to land
them via a true merge.

I expect the above to take a few days. Then again, it might
be well progressed 24 hours from now depending on who else
has time to help. vila? jam?

And another idea to think about ... and discuss politely (please).

IIUIC, Bob has made the decision as RM to release 1.14rc today.
I assume the date for 1.14 will then be April 9. We want to
ensure that those users who *want* to test the next-gen format
have a low barrier to entry with everything correctly built
with the right version of pyrex, the right version of compilers,
etc. Telling them to run bzr.dev is simply too high for some,
particularly on Windows. As an alternative to cherrypicking the
new code into the 1.14 release, we could release a 1.15beta at
the same time as 1.14final ships. End users can then make the
decision as to which version to install. *However*, this
is only a sensible option if those packaging for the various
platforms can commit to do it for both versions, hopefully
over Easter. Now 1.14 may slip or 1.15beta may slip but releasing
both simultaneously, if we choose to have 2, feels a sensible
goal to me. The packaging burden isn't small, so if we decide
to do this, please step forward to help if you can. (It's fine
to have great ideas on an ideal process but it always takes
manpower in the end, or the path of least resistance wins out.)

Ian C.