New 1.14 RC date?

[Michael B. Trausch]

On Fri, 03 Apr 2009 17:31:43 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Fifth, it's not clear how much Talden's schedule needs to slip.  It
> goes into bzr.dev immediately after the release[1], and will get a lot
> of testing from bzr.dev users, including serious support from the
> Emacs people, fer sure.  I suspect somebody will try to build on
> Windows, and succeed.  On his end, I doubt that he'd be able to
> convince anybody with a fresh release as a --development format; it
> will be two or three releases before it's a standard format and
> becomes even thinkable.  Does a month of testing on Windows now really
> matter so much to a process that would probably not start for another
> two months at least anyway?  (That is, of course it matters, but it's
> not necessarily a full month's delay for him, not if everything goes
> as well as he is assuming it will to justify a rushed release.)
[...]
> Footnotes: 
> [1]  I'm surprised that's not part of the process definition.  One
> week of work landing features, two weeks reviewing and if necessary
> reverting ones that can't be fixed, one week prep, release.  Something
> like that.

Isn't this something along the lines of how the Linux kernel works
these days?  Starting from a releases (let's say, 2.6.29):

  * Linus cuts Linux 2.6.29[.0]
  * Linus then opens a "merge window", which lasts for a while, for
    the 2.6.30 kernel.
  * After the merge window is closed, a series of interim releases
    leading up to 2.6.30[.0] is made.  For 2.6.29, I believe there
    were 9 interim releases in the three-month cycle.
  * Sometime in June or July, Linus cuts Linux's 2.6.30[.0] release.

Even so, sometimes issues happen.  For 2.6.29[.0], there was a serious
networking issue that was introduced sometime between -rc9 and the
final, which was addressed by today's (yesterday's, for some) release of
2.6.29.1.  I don't know _why_ that happened, but it caused me to be
unable to use 2.6.29 until someone came up with some patches to fix the
problem.  (Even so, I wound up deciding to wait for 2.6.29.1 in order
to go back to running a vanilla kernel.)

I'd assume that there are a fair amount of people who are running
bzr.dev and would be happy to test out the new functionality after it
lands in there.

It looks to me, assuming that I did this correctly, that this is a
pretty significant code drop; taking lp:~bzr/bzr/brisbane-core and
merging it into lp:bzr, there's one (easy to resolve) conflict, no
biggie there, but the diffstat is pretty large with a total of
somewhere around 13,650 changes being made in that drop; to compare,
the number of changes from 1.13.1 to the current dev tree is around
32,400 changes; so brisbane-core's drop is roughly 40-45% of the size
of the changes for the entire last release.  It'd seem to me a decent
idea to hold off on that until the 1.15 "merge window".

So, just my 2¢, but hopefully not taken the wrong way.  I am quite
anxious to see the new features that are coming down the pike.

	--- Mike