Re: Kernel schedule proposal for Etch
Frederik Schueler wrote:
> 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 
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
> 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 
> 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
>  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.
>  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 <firstname.lastname@example.org>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...