Frederik Schueler wrote: > Hello, > > we should finally agree on which kernel version we want to release etch > with, and on an appropriate timeframe. > > The goal should be obvious: release Etch on December, 4th. > > All kernel team members I asked so far would prefer a release with > 2.6.18, which is likely to be released upstream within the next 4 weeks. > The Debian installer team obviously would like as much time as possible > to find out and fix all emerging bugs. > > Trying to put both requirements together, the kernel release schedule > could look as follows: > > today: start migration of 2.6.17 kernel and udebs to testing > > 15.09: upload 2.6.18 to unstable [1]
This is barely feasible. It would mean that the kernel team will have to spend the next month doing the work to make 2.6.18 DFSG-free. This could of course be done very quickly by stripping out all the problematic drivers, but this would probably be a very bad solution from the installer point of view. > 01.10: migrate 2.6.18 kernel and udebs to testing > > 04.11: freeze kernel - No more changes to the testing version. Start of > security support for the kernel on security.d.o [2] > > 04.12: release > > > I would like to keep the non-free firmware discussion as a separate topic, > thus it is not considerer in this schedule. That's simply unrealistic. Ignoring what amounts to about 50 RC bugs in designing a schedule is just.... stupid. > I'd like some feedback from both the installer and release team if they > think this is a feasible way for further action; if so, I'll also > contact the security team for begin of security support. > > Best regards > Frederik Schueler > > > [1] The 2.6.18 release obviously depends on the upstream schedule, but 4 > weeks from now is realistic considering the 2.6.18-rc4 status. > > [2] Kernel freeze as in: security fixes will go into a branch targeted > at security.d.o and proposed-updates. We won't touch the kernel in Etch > after the freeze, That means it *must* be DFSG-free. See above. For the smoothest results, the upload of a DFSG-free kernel (which is to say, a freezable kernel) should come after the installer is capable of loading non-free kernel modules from separate non-free udebs. So the design of a plausible kernel upload schedule is primarily dependent on non-free udeb support. Anyone know what the ETA for that is? > but for extreme security issues affecting the > installation process, like remote root exploits. All other issues will > be addressed as needed in a security update and future point releases. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]