On Tue, May 16, 2006 at 10:47:50AM +0200, maximilian attems wrote: > i disagree for the 2.6.16 choice, will point out the args as following. > * sarge released with an more than one year old kernel > that was bad as new hardware from the sarge release day on was not > supported (d-i jump to the vc2 wget newer image and be fine sure, > but that is not the support d-i customers deserve). > especially bad as the 2.6.8 acpi was crap, the sata support almost null, > vm bad under high load or mem pressure, nfs flacky.. > > 2.6.16 was released on Mar 2006, if the next release gets out of the door > dec/jan 2006/07 we get this same bad situation of an year old kernel to > support. >
... <list of good examples of why 2.6.16 will grow stale> ... I agree that we are in a bad state with 2.6.8, and there is a potential that freezing on 2.6.16 will put us in the same state. I've had a few conversations at DebConf about how we can add a newer upstream kernel in a stable point release; I'll bring this up in a separate discussion thread with a broader audience because I think it is a mostly unrelated discussion[1]. However, to meet the etch release schedule, we need to begin freezing the kernel relatively soon. I am not sure what those dates are though; hopefully this will become more clear after the etch release discussion at debconf on Thursday (iirc). The bit I find interesting about 2.6.16 is that Adrian Bunk has proposed maintaining a 2.6.16 branch where new *features* are permitted, and it sounds more inline with how 2.4 was maintained once 2.5 had forked. If this happens, it *should* provide a more controlled tree than Linus' from which we can pull in updated features like atapi, acpi, etc, and continue to sync them into our testing kernel until the freeze. If we could have trivially cherry-picked features from 2.6.10 and backported to 2.6.8 before sarge, I think we would have; but the number of changesets between the two was so immense that we only really considered moving completely to 2.6.10. If it turns out that the bunk tree does not receive the feature/driver updates we want, I agree that it is probably not the right base for etch. Of course, it may mean that we get to do the backports and convince Adrian to accept them :) [1] Unrelated because I think we should be picking the kernel with the most stable user-desired features that will be available in time to meet our release schedule, without counting on this possible update later. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
