Back when 2.2 kernel series was out, nobody thought even began to think about upgrading their kernel to 2.4 series until 2.4 became 2.4.10 or better. This was because of the problems known to happen in the early 2.2 and 2.0 series. Lately with this new 2.6 kernel things seem much more mature but even I can be counting my chickens before they hatch.
Gentoo on the other hand along with many other competitors follows the same suite of testing. We test until it can't be tested anymore and by the time it's done a new version might be out but we can apply 90% entire gentoo patchset with only minor fixes for the remaining 10%. Why should Gentoo put on it's users a product that doesn't work for them. This makes users happy to have something running and if your brave you can run 2.6, we offer both kernels so the user's happy and we get some bug reports to fix 2.6 bugs as they come. When we feel confident that it's running smooth and we'll get only a few bug reports for making it the next vanilla kernel, that's when we'll make it vanilla. Thanks, Benjamin Coles Gentoo Infrastructure On Wed, 2003-12-24 at 04:55, Markus Nigbur wrote: > On Wed, 24 Dec 2003 13:35:54 +0100 > Christian Gut <[EMAIL PROTECTED]> wrote: > > > I always thought about vanilla, that it reflects the exact state of > > kernel.org so they said its stable it should go stable in its ebuild. > > Further on should one report bugs to gentoo devs when they didn't > > change anything in the kernel except packaging it? So i don't see the > > point why one expect bug reports there... > > it does depend on some more stuff than just the kernel. for example > kernel headers or nptl support in glibc. apparently not every package > does compile correctly with 2.6 kernel and kernel headers yet. same > applies to nptl stuff. > what i want to say here is, the kernel devs won't be too happy to get > flooded by kernel bugs that aren't related to the stock kernel, but the > system around the kernel. > > But i see ciaranm's and kumba's points, so it might really be the better > solution to have them in development-sources for now. > > -- Markus
signature.asc
Description: This is a digitally signed message part
