maximilian attems <[EMAIL PROTECTED]> writes:
> 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..
This was mostly caused due the risk of the kernel to not be ready on
time. We do need to have a better process to avoid those two problems
to happen from now on.
<...>
>> 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.
But it would accelerate the d-i migration since we could mostly of
time do the switch at same time of kernel going sid.
>> 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.
No. experimental is the place for that.
>> 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.
It is different case when we are working with a full set of
architectures and planning to not hurt users.
You need to agree that if one derivative breaks, it hurts much less
people then if oficial d-i breaks.
>> > > 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.
And how about the other and correlated changes that would be need like
toolchain and base? We're on _freeze_, bear that on mind.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
