New 1.14 RC date?

[Robert Collins]

On Wed, 2009-04-01 at 22:13 +1000, Ian Clatworthy wrote:
> I'd like to hold off doing the 1.14rc release this Friday and
> target Wed/Thu next week say, instead. The chk stuff looks
> like it's coming along nicely but I can't see us merging it
> all into bzr.dev this week in a safe, fully reviewed way.

And boy what a thread we got :).

Bob, this is your call - you are the RM. Say the word and I'll make the
branch now on PQM for you.

I want to throw more info into the mix though.

Firstly, Martin is away from his computor for a little bit which is why
he hasn't chimed in on this; he suggested [verbally, sigh :)] that this
was an appropriate thing to do though before he went. 

A delay like this has precedent, and it has worked well, and poorly in
the past. Its worked poorly when the thing being added was added as a
'must use' rather than a 'available for test'.

The code to be added consists:
 - A new Inventory sibling class with common code pulled up to
CommonInventory
 - The new format and supporting logic like xdiff3, groupcompress
CHKMap 
 - support for the knit api to generate keys by the sha1 of content
 - a new flag on repository format, supports_chks.
 - a patch to StreamSource which needs to be reverted now that there is
a custom StreamSource [approved but jam hasn't landed it]
 - a InterTree for CHK Revisions
 - testing support changes to allow testing the new InterTree
 - tests for all the above.

So while I can't quite say 'there are no changes to other core code' [if
I could, this could be in a plugin :)', I can say 'All the
major/risky/intrusive changes to core code are already merged'.

Merging this branch isn't a high risk for destablising the core; and
unless a user runs init --development they won't interact with the new
code at all.

I want to be clear that this isn't some 'For eamcs'. Its 'for us and our
users'. Getting this code into trunk means several things will happen:
 - We get all the normal review support as the project would no longer
   be in a separate branch
 - Focus would no longer be divided between bzr.dev and brisbane-core;
brisbane-core could be deleted.

Getting it into 1.14 means:
 - we *can* ask people that are interested to try the --development
flag.
 - plugin authors have a longer period to work with the new features and
API's before it becomes a production format. (Again, while you can argue
that they should check bzr.dev, plugin authors often don't).

I appreciate the arguments that we could tackle the challenges presented
in a different way - more branches, more development builds etc. Those
arguments are largely correct though I feel that they really don't
appreciate the significant inertia involved in getting people to change
their apt sources [or whatever tool they use]. Some users are very
flexible, others are not. Nevertheless, I feel confident in saying that
there is a manpower problem here - time taken to do that is either time
not being spent on brisbane core, or is time provided by a volunteer
stepping up to the plate. Warning though doing windows builds alone is a
time consuming process (its been known to make John disappear for weeks
at a time) - doing twice as many builds on anywhere near as many
platforms as bzr is built for by existing volunteers is a lot harder
than the *existing approach* of 'development formats'.

Finally we seem to also have gotten into conflated arguments. This
thread was meant to be about 'a small delay'. Instead its become about
'should this be merged before its really really finished'. If a simple
merge request had come through the day after the RC, I doubt anyone
would have blinked, and yet, it still would mean that 1.15 shipped a
'development format'.

-Rob 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090403/ae779342/attachment.pgp