[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 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.


Reply to: