Messages in this thread | | | Date | Wed, 02 Mar 2005 15:26:09 -0800 | From | "Randy.Dunlap" <> | Subject | Re: RFD: Kernel release numbering |
| |
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 - 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/
| |