Re: RFD: Kernel release numbering

["Randy.Dunlap" <rddunlap@osdl.org>]

Jeff V. Merkey wrote:
> 
> __Stable__ would be a good thing. The entire 2.6 development has been a 
> disaster from
> a stability viewpoint. I have to maintain a huge tree of patches in 
> order to ship appliance
> builds due to the lack of stability for 2.6. I think that the even 
> number releases will take longer but it's worth the wait.
> 
> Jeff

Linus's release cycle estimate might be optimistic.  :)

I'm seeing lots more bug reports recently than I care to see.  :(

> Linus Torvalds wrote:
> 
>> This is an idea that has been brewing for some time: Andrew has mentioned
>> it a couple of times, I've talked to some people about it, and today 
>> Davem
>> sent a suggestion along similar lines to me for 2.6.12.
>>
>> Namely that we could adopt the even/odd numbering scheme that we used 
>> to do on a minor number basis, and instead of dropping it entirely 
>> like we did, we could have just moved it to the release number, as an 
>> indication of what was the intent of the release.
>>
>> The problem with major development trees like 2.4.x vs 2.5.x was that 
>> the release cycles were too long, and that people hated the back- and 
>> forward-porting. That said, it did serve a purpose - people kind of 
>> knew where they stood, even though we always ended up having to have 
>> big changes in the stable tree too, just to keep up with a changing 
>> landscape.
>>
>> So the suggestion on the table would be to go back to even/odd, but do 
>> it at the "micro-level" of single releases, rather than make it a two- 
>> or three-year release cycle.
>>
>> In this setup, all kernels would still be _stable_, in the sense that we
>> don't anticipate any real breakage (if we end up having to rip up so much
>> basic stuff that we have to break anything, we'd go back to the 2.7.x 
>> kind
>> of numbering scheme). So we should fear odd releases, but track them, 
>> to make sure that they are good (if you don't track them, and problems 
>> won't be fixed in the even version either)
>>
>> But we'd basically have stricter concerns for an even release, and in
>> particular the plan would be that the diff files would alternate between
>> bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
>> 2.6.11->12 release would be a "stability only" thing, and hopefully the
>> diff file would be much smaller).
>>
>> We'd still do the -rcX candidates as we go along in either case, so as 
>> a user you wouldn't even _need_ to know, but the numbering would be a 
>> rough guide to intentions. Ie I'd expect that distributions would 
>> always try to base their stuff off a 2.6.<even> release.
>>
>> It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
>> kind of even/odd thing didn't _work_, the problems really were an 
>> issue of
>> too big granularity making it hard for user and developers alike. So I 
>> see
>> this as a tweak of the "let's drop the notion althogether for now"  
>> decision, and just modify it to "even/odd is meaningful at all levels".
>>
>> In other words, we'd have an increasing level of instability with an 
>> odd release number, depending on how long-term the instability is.
>>
>> - 2.6.<even>: even at all levels, aim for having had minimally 
>> intrusive   patches leading up to it (timeframe: a week or two)
>>
>> with the odd numbers going like:
>>
>> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading 
>> up   to it (timeframe: a month or two).
>> - 2.<odd>.x: aim for big changes that may destabilize the kernel for   
>> several releases (timeframe: a year or two)
>> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>>   the kernel to be a microkernel using a special message-passing 
>> version   of Visual Basic. (timeframe: "we expect that he will be 
>> released from   the mental institution in a decade or two").
>>
>> The reason I put a shorter timeframe on the "all-even" kernel is 
>> because I
>> don't want developers to be too itchy and sitting on stuff for too 
>> long if
>> they did something slightly bigger. In theory, the longer the better
>> there, but in practice this release numbering is still nothing but a hint
>> of the _intent_ of the developers - it's still not a guarantee of "we
>> fixed all bugs", and anybody who expects that (and tries to avoid all 
>> odd release entirely) is just setting himself up for not testing - and 
>> thus bugs.
>>
>> Comments?


-- 
~Randy