Re: RFD: Kernel release numbering

Randy.Dunlap
2005-03-02T23:34:12Z

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