lkml.org 
[lkml]   [2005]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: starting with 2.7
Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 04:19:17PM -0800, William Lee Irwin III wrote:
>
>>On Sun, Jan 02, 2005 at 01:42:11PM -0800, William Lee Irwin III wrote:
>>
>>>>This is not optimism. This is experience. Every ``stable'' kernel I've
>>>>seen is a pile of incredibly stale code where vi'ing any file in it
>>>>instantly reveals numerous months or years old bugs fixed upstream.
>>>>What is gained in terms of reducing the risk of regressions is more
>>>>than lost by the loss of critical examination and by a long longshot.
>>
>>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote:
>>
>>>The main advantage with stable kernels in the good old days (tm) when 4
>>>and 6 were even numbers was that you knew if something didn't work, and
>>>upgrading to a new kernel inside this stable kernel series had a
>>>relatively low risk of new breakages. This meant one big migration every
>>>few years and relatively easy upgrades between stable series kernels.
>>
>>This never saved anyone any pain. 2.4.x was not the stable kernel
>>you're painting it to be until 2.4.20 or later, and by the time it
>>became so the fixes for major regressions that occurred during 2.3.x
>>were deemphasized and ignored for anything prior to 2.6.x.
>
>
> I don't know which specific regressions you have in mind, but for
>
>>95% of the users 2.4 is a pretty usable kernel.
>
>
>>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote:
>>
>>>Nowadays in 2.6, every new 2.6 kernel has several regressions compared
>>>to the previous one, and additionally obsolete but used code like
>>>ipchains and devfs is scheduled for removal making upgrades even harder
>>>for many users.
>>
>>My experience tells me that the number of regressions in 2.6.x compared
>>to purportedly ``far stabler'' kernels is about the same or (gasp!)
>>less. So the observable advantage of the ``frozen'' or ``stable'' model
>>is less than or equal to zero.
>>
>>Frankly, kernel hacking is a difficult enough task (not that I
>>personally find it so) that frivolous patches are not overwhemingly
>>numerous. The ``barrier'' you're erecting is primarily acting as a
>>barrier to fixes, not bugs.
>
>
> My point is different.
>
> Perhaps the number of fixes for bugs equals the number of new bugs
> in 2.6 .
>
> But it's not about the number of bugs alone. The question is the number
> of regressions compared to a previous kernel in this series.
>
> 2.4 -> 2.6 is a major migration.
>
> 2.4.27 -> 2.4.28 is a kernel upgrade that is very unlikely to cause
> problems.
>
> Compared to this, 2.6.9 -> 2.6.10 is much more likely to break an
> existing setup that worked in 2.6.9 .
>
>
>>On Sun, Jan 02, 2005 at 11:15:34PM +0100, Adrian Bunk wrote:
>>
>>>There's the point that most users should use distribution kernels, but
>>>consider e.g. that there are poor souls with new hardware not supported
>>>by the 3 years old 2.4.18 kernel in the stable part of your Debian
>>>distribution.
>>
>>Again, the loss of critical examination far outweighs the purported
>>defense against regressions. The most typical result of playing the fix
>>backporting game for extended periods of time is numerous rounds of
>>months-long bughunts for bugs whose fixes were merged years ago upstream.
>>When the bugs are at long last found, they are discovered to fix the
>>problems of hundreds of users until the next such problem surfaces.
>
>
> The main question is, whether it might be possible to make a very short
> 2.7 line (< 6 months).
>
> Imagine e.g. a feature freeze for 2.6 now. Then 2.7 starts with a
> feature freeze for 2.7 one or two months later. During this time, all
> the changes that do now flood into 2.6 would go into 2.7, and then
> there are a few months of stabilizing 2.7 .
>
> It's quite the opposite of the current 2.6 model, but a quick 2.8 should
> also avoid this problem you describe.
>
> Basically, in this proposal (if it started today), what was expected to
> be called 2.6.11 will be called 2.7.0, and 2.6.11 will be a bugfix-only
> kernel (considering the amount of changes more like the current -ac than
> the latest -mm).

The development policy is set by majority vote on a regular basis.
However, since only one vote counts and Linus prefers it the way it is,
we live with it. In my opinion the stable series is -ac, Alan actually
runs the kernels.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.828 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site