Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote:
> On Monday 07 July 2008, maximilian attems wrote:
> > > There are valid arguments to be found for staying with 2.6.25 a bit
> > > longer, but "D-I has not yet converted to it" is NOT one of them.
> >
> > testing users are currently on an unsupported kernel.
>
> Eh, how does that follow my last para which I assume you are commenting
> on, but which has nothing to do with testing?
>
> A side-note to your comment though...
>
> IMO testing kernel support is the weakest point in the current upload
> strategy by the kernel team. By uploading the next upstream release to
> unstable basically as soon as it's available upstream, Debian users (both
> unstable and testing) are frequently missing out on at least one or two
> upstream stable updates for the previous stable ("stable -1") release.
agreed on the week point, but not to your conclusions.
it often happens that d-i is blocking on older release.
like the beta that happened to want to stick to 2.6.22
which was a pure catastrophe, half a year too old, without
support for e1000e and newer intel boards..
> We worked around this for .24 by doing an upstream stable update through
> t-p-u.
dannf did and he is from the kernel team.
it was not a workaround, but again a stick to previous instead of
working forward.
> Upstream does seem to recognize the fact that a new release will need at
> least a few updates before it is actually "stable and usable", and will
> therefore do at least a few stable updates (for both "new stable"
> and "stable -1" in parallel). This basically happens in parallel to the
> new merge window (say the time to -rc2) and some upstream releases get
> "longer term" upstream stable support (.18, .22, .25).
.22 didn't stay long with us. this was said back then for .16 and
didn't matter on the long run.
> My personal opinion is that it would be better to delay the upload of new
> upstream releases to unstable until the .2 or maybe even .3 upstream
> stable update has become available. This would mean a bit more work for
> the kernel team, but I would expect that to be solvable.
don't see any point on that.
it wouldn't accelerate the meta package sort.
> That would also give more time for initial arch-specific and l-m-e issues
> for the new upstream to be worked out (e.g. in experimental) without
> breaking unstable too much. IMO a new kernel version should only be
> uploaded to unstable if kernel meta packages can be updated at roughly
> the same time.
this is a currently a week point, but unstable is the place to sort
such.
> It would also allow to upload a few more stable updates for "stable -1"
> and to migrate those to testing, giving testing users on average better
> support and it would give D-I some more "breathing space" to do releases.
>
> When a new stable *is* uploaded, D-I should be able to switch faster too
> (at least, if there's someone willing to do the initial kernel-wedge
> work) as the main criterium for D-I to switch to a new kernel version is:
> does the new version look about to be ready to migrate to testing, which
> current early uploads of the kernel to unstable effectively never are.
<sarcastic mode on>
never seen that, d-i has always been dragging.
<sarcastic mode off>
would wish that kmuto be an official d-i member. he even
tracks rc snapshot releases when necessary.
> > > A much more important argument is that .25 has seen and will almost
> > > certainly continue to get a lot more stabilization effort upstream
> > > than is "normal" for upstream kernel releases because long term
> > > releases for at least two important other distros are based on it. I
> > > doubt .26 will get the same upstream attention.
> > > Given the lack of capacity in Debian to do any real stabilization
> > > (cherry picking/backporting of fixes from later releases) ourselves,
> > > that could IMO be an important consideration for staying with .25 for
> > > Lenny.
> >
> > that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
> > biest you'll notice the RH men force boot behind their backporting
> > machine.
>
> I'm having serious trouble parsing what you're trying to say here. Could
> you rephrase?
you never checked the rh kernel. they do a *lot* of backporting and
have a big team working on that. so you'll notice that none of those
patches landed in ours. so your argument sounds nice, but doesn't
help in practise.
.26 got a *lot* upstream attention and solves a number of .25 regressions.
it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless
improvements, allmost net namespaces and uvc cam support.
--
maks
Reply to: