Re: Release 2.12 - 3.0

[Pratyush Kshirsagar <pratyush.kshirsagar@xxxxxxxxx>]

I vote for (A)

On Tue, Oct 18, 2011 at 12:09 PM, Alex Hornung <ahornung@gmail.com> wrote:

Hi all,

for those too lazy to read most of this mail, skip to "In a summary".

In its current state, 2.12 has fairly major problems in the VM subsystem
that can lead to random bus faults, etc. The underlying issue is that
pages randomly become zero-filled. Symptoms seem to include random full
machine lockups, random bus faults (particularly popular during pkgsrc
building), etc. In my opinion releasing 2.12 like this is a no-go.

On the bright side, Matt has been working hard on effectively rewriting
the locking of the VM system. The outcome is a huge improvement in
performance and, incidentally, something that fixes most bugs, including
the above. But reality is, as awesome as the changes are, they need
testing, and a lot of it. There is no way we can ship this any time soon
as a release.

====

In a summary: 2.12 is broken and the fixes for it need plenty of testing
(months of testing).

There are a few solutions that have been proposed for this, and I'd like
people to vote on them, since we really need to make a decision ASAP:

A) Scrap the 2.12 release completely (since it's broken anyway and I
don't think releasing something that we know is broken is a good idea)
and simply continue our release schedule with 3.0 some time in the new year.

B) Revert some of the VM fixes that went into 2.12 that actually made
the problem worse. This also takes time and a lot of testing, but should
make it possible to release something less broken (but still broken) in
about a month's time.

C) Release 3.0 pretty much now, but risk releasing something broken,
too, since the major VM changes also require major testing - for which
we simply don't have time in this short timeframe.

D) Release the broken 2.12 and let users "suck it up".

====

My vote goes to (A). I feel it is the only way to:
1) avoid shipping broken software (option C and D), and
2) avoid wasting time on stabilizing something that is already obsolete
(option B).


Cheers,
Alex Hornung