Re: which kernel version for etch?

[Sven Luther <sven.luther@wanadoo.fr>]

On Tue, May 16, 2006 at 10:47:50AM +0200, maximilian attems wrote:
> hello,
> 
> On Thu, 11 May 2006, dann frazier wrote:
> 
> > On Tue, May 09, 2006 at 11:46:32PM +0200, Frederik Schueler wrote:
> > > Fellow Debian kernel team members,
> > > 
> > > let's take the recent "bits from the release team"[1] as an opportunity
> > > to start discussing which kernel version we, the Debian kernel team, 
> > > want Etch to release with.
> <snipp>
>  
> > > Considering the current upstream 2.6 development model on one side, 
> > > and Adrian Bunks intention to maintain 2.6.16.x for the next 2-3 years 
> > > on the other side - backporting drivers and other updates like the 2.4 
> > > line is handled -, makes the 2.6.16.x line an ideal candidate for the 
> > > purpose of a release kernel for Etch.
> > 
> > I agree; at this point 2.6.16.x looks ideal.  I stress "at this point"
> > though; we of course shouldn't make this decision irreversible.
> > Especially if, as Sven noted, Andrew Morton decides to maintain a .17
> > or .18 in a similar manner.
> 
> 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..

Notice, that what you are advocating, means fast d-i kernel upgrades, as well
as fast out-of-tree modules rebuild.

Andreas, i would appreciate if during that meeting, you could mention to the
d-i team the possibility of re-integrating all d-i kernel .udebs into a single
source package for all arches, instead of the disparate situation we have
right now. As it seems the technical hurdles for this where removed a couple
of month ago, this would make sense and would allow for a two-step upload
(kernel .deb and then kernel .udeb), compared to the mess it is today.

Friendly,

Sven Luther