On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote: > On Fri, 18 Feb 2011, Michael Gilbert wrote: > > This will also help to provide a bit more stability for CUT [0]. Over > > a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream > > kernels will be released, and each new kernel comes along with a high > > probability of introducing breakage. I'm trying to provide CUT > > releases once a month, so every 3 months I will be looking at a likely > > broken CUT release (or 25% of the time). However, if there is just one > > kernel transition in testing development cycle, then there is only 1 > > likely broken period (or 4% of the time). > > The kernel is not the sole component that can introduce breakage. So it > seems ridiculous to do such statistics based on the kernel only.
Hi Raphael, I completely concur that there are indeed other important components like grub and xorg where breakage would be a showstopper. However, I don't think the consequences would be quite so substantial. There is just so much intimately dependent on the kernel that breakage there has a very wide area of effect; whereas grub or xorg breakage is somewhat contained. This is why I'm only significantly concerned about the kernel. Anyway, I agree that there will be breakage, but I don't want CUT to be mostly about constantly resolving the same repetitive kernel breakage. Also, this solution isn't just about CUT stability. As I've been describing, it is about killing about 2 birds with one stone: 1. Make testing always installable by retaining a stable/well-tested kernel and associated d-i infrastructure 2. Improve testing security by reducing the amount of vulnerabilities existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as described previously) In fact these are two of the three known problems in testing mentioned in your LWN article [0]. And the only consequence is that testing users don't get the latest kernel bling. However, that is offset by the availability of 2.6.37 and associated infrastructure in unstable. So there really are no downsides that can't be worked around with a little education/effort on the part of the user. > And like Lucas said, CUT users want recent software and that includes the > kernel I don't think it is appropriate to project a singular perspective onto all users. Ultimately our goal is to perform a balancing act between freshness and stability. In the past the primary focus has been on freshness in testing, but I think there is room to swing the pendulum a bit more toward stability. It's really a requirement if we're ever going to be able to achieve something a testing that's "constantly usable". Also, users needing bleeding-edge freshness can always take the plunge into unstable. > (which is also important for new hardware support). This seems to be a meme that continues to persist without much in the way of evidence. It certainly may have been true in the past, but I think things have changed for the better with the advent of stable upstream support (i.e. support for new hardware is backported to the stable kernels). Also, I've read about 10 reviews of squeeze, and none of them have indicated any problems with hardware support (except for missing support for non-free firmware) even though that uses a kernel initially released almost a year and a half ago. In fact, I've only ever had one piece of hardware (a wireless card) that was unsupported by Debian, and that was when sarge was still in testing, and all that was needed was to enter the device id into the discover list. It wasn't even a kernel issue. Ultimately I don't see why the newest blingy kernel is a necessity in testing. Best wishes, Mike [0] http://lwn.net/Articles/406301/ _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
