On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: > > On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: > > > * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: > > > > On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > > > > > You are ignoring that we have scheduled a time to update the kernel > > > > > again before release of etch. > > > > > > > > Ah, nice. But would this include an abi-changing kernel upgrade ? I > > > > fear not, > > > > given the trouble of abi changes for security upgrades. In any case, it > > > > doesn't include an upstream kernel version bump in the planes i have > > > > read, > > > > right ? > > > > > > It would even allow a newer minor kernel version, so an abi-change > > > should be possible as well. > > > > Nice then, the question remains of how often and in what timeframe we can do > > such. Imagine there is a security issue shortly before the release, will we > > say like last time, let's ship with it, because we have not put into place > > the > > procedure to handle it in a timely fashion ? > > There will definitly be a time when it is too late to replace the kernel > without delaying the release (just consider that we e.g. notice after > starting the CD build that there is some issue). Also, we need a minimum > testing periode for the final kernel and the final installer. If we set > that minimum testing periode to something like 6 weeks (which seems sane > to me), we cannot update the installer later than mid of October, and > the kernel needs to be a little bit earlier, which is like the beginning > of October.
Err, do you really need to retest everything when a kernel change only includes a small set of security fixes ? I think 6 weeks may be overkill there, unless naturally you are speaking of a version bump with a huge load of changes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
