Re: Kernel schedule proposal for Etch

[Nathanael Nerode <neroden@fastmail.fm>]

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  <neroden@fastmail.fm>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...