| |||||||||||||
|
| |||||||||||||
Release management issuesRelease management issuesPosted May 29, 2003 22:11 UTC (Thu) by iabervon (subscriber, #722)Parent article: Release management issues It seems logical to me that 2.6-pre would signal a proper freeze; the deadline-based freeze is fine for determining when to stop including new stuff, but a numbering system change should be required to go from kernels which aren't supposed to be stable (2.5.X) to kernels which would ideally be stable but aren't (2.6-preX) to kernels which actually are stable (2.6.X). Of course, the 2.6-preX series should probably be about 50 kernels (judging by the 2.4 stabilization), but making sure that things head towards 2.6.X and 2.6.0 doesn't come out broken is Andrew's job, and Andrew's job only starts with 2.6-pre1 (or, I suppose, the moral equivalent). It's unreasonable to except that the first non-development kernel will be not entirely broken, because the last development kernel, by definition, includes new development which has not been widely tested. On the other hand, I'm not entirely convinced that development is done or nearly done. What would be interesting, actually, is a list similar to the 2.6.0 must-fix list of 2.6-pre "must-break" items; all of the remaining destabilizing changes which are expected in the 2.6 timeframe.
(Log in to post comments)
|
|
||||||||||||