DragonFly BSD
DragonFly kernel List (threaded) for 2011-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Release 2.12 - 3.0

From: Stathis Kamperis <ekamperi@xxxxxxxxx>
Date: Tue, 18 Oct 2011 19:41:39 +0300

2011/10/18 Alex Hornung <ahornung@gmail.com>:
> 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).

I vote (A). If not (A) then (C).

> Cheers,
> Alex Hornung


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]