On Mon, Jul 07, 2008 at 04:19:01PM +0000, Aurelien Jarno wrote:
> Frans Pop a écrit :
> > Se IMO we should take a real good look at .25 and .26 and check what's
> > new, what's important for Lenny and what's risky, and maybe check if some
> > things we do want could be backported.
>
> As the release team is Cc:ed, I just want to make sure it is aware that
> switching to 2.6.26 possibly means changes to userland, and thus freeze
> exceptions. A few examples:
>
> - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to
> removed headers. Change have been needed in various packages including
> glibc.
> - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently
> FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know
> yet which change causes the problem, I am down to a 600 lines diff.
> - I have recently uploaded a new version of lm-sensors needed to support
> 2.6.26 kernels.
>
> That said I neither opposed nor in favor of a switch to 2.6.26, I just
> want to emphasize that it can have a bigger impact than expected on the
> release planning.

Changing kernel at this point of the release would be too destructive,
so unless there is a big fat problem in the .25 that the .26 should fix
and is unbackportable (does such a beast even exist ?) I'm rather
opposed to it. Note that the asm/page.h mess is still not fixed thanks
to hppa.

Disclaimer: it's my own opinion, I did not check what other Release Team
member think about this.

--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org

* Pierre Habouzit (madcoder@debian.org) [080707 19:48]:
> Changing kernel at this point of the release would be too destructive,
> so unless there is a big fat problem in the .25 that the .26 should fix
> and is unbackportable (does such a beast even exist ?) I'm rather
> opposed to it. Note that the asm/page.h mess is still not fixed thanks
> to hppa.
>
> Disclaimer: it's my own opinion, I did not check what other Release Team
> member think about this.

I agree with you, at least with my current informations.


Cheers,
Andi
--
http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

maximilian attems <max@stro.at> writes:

> .26 is the release kernel.
> so i'm happy with push on it.
> .25 is a possible backup.

I'd like to get an official statement from RM team about that so we
can move it further.

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org 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 debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Michlmayr <tbm@cyrius.com> writes:

> * Frans Pop <elendil@planet.nl> [2008-07-07 17:30]:
>> In fact, having 2.6.25 in testing would possibly make it easier for
>> the kernel team to do a final (?) 2.6.25 upload with latest stable
>> updates.
>
> FWIW, I fully agree. In the past, we never waited for all arches in
> d-i to move to a new kernel udebs before allowing the deb of that
> version to move to testing. In fact, not having 2.6.25 in testing now
> that some arches have updated d-i to 2.6.25 _hurts_ our testing
> efforts. Some Orion devices work perfectly fine in d-i now that we've
> moved to 2.6.25, but installations fail because no kernel is in
> testing... which means people cannot test it.
>
> So, please migrate the 2.6.25 debs to testing.

No objection in allowing 2.6.25 to go to testing but please hold on
about uploading 2.6.26 until RM team acks on it.

- --
O T A V I O S A L V A D O R
- ---------------------------------------------
E-mail: otavio@debian.org 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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAkhyZJAACgkQLqiZQEml+FUgZwCfUX/L+aGf7m4sk0rsAua3M3Eo
4SAAoJFrBJQgdwpJ4y+FHgUPEdAUFkTF
=i8PB
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Otavio Salvador wrote:
> Martin Michlmayr <tbm@cyrius.com> writes:
>
>> * Frans Pop <elendil@planet.nl> [2008-07-07 17:30]:
>>> In fact, having 2.6.25 in testing would possibly make it easier for
>>> the kernel team to do a final (?) 2.6.25 upload with latest stable
>>> updates.
>> FWIW, I fully agree. In the past, we never waited for all arches in
>> d-i to move to a new kernel udebs before allowing the deb of that
>> version to move to testing. In fact, not having 2.6.25 in testing now
>> that some arches have updated d-i to 2.6.25 _hurts_ our testing
>> efforts. Some Orion devices work perfectly fine in d-i now that we've
>> moved to 2.6.25, but installations fail because no kernel is in
>> testing... which means people cannot test it.
>
>> So, please migrate the 2.6.25 debs to testing.
>
> No objection in allowing 2.6.25 to go to testing but please hold on
> about uploading 2.6.26 until RM team acks on it.

hint added.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Monday 07 July 2008, Frans Pop wrote:
> .26 also includes at least one change I know of that is somewhat risky:
> PAT support for x86 (which could be disabled).

#d-uk just gave me this tidbit:
<...> am I missing something or will the move to .26, with libata binding
before most of the IDE stuff, cause a lot of pain unless the distro
manages the move from hd* to sd*?

Which is basically the "why don't we have persistent device naming" issue
(on which I won't comment).

There's two things to say about this (assuming status quo otherwise):
- this will probably reduce the pain on reboots for new installations
as module loading order should become more predictable between different
boots
- this may increase the pain for people upgrading from Etch to Lenny,
or not, or ...


Other related issue/question.

Early in lenny, when libata first stuck up its head, we made some effort
to disable drivers or remove duplicate PCI IDs so that existing users
using the "old" IDE drivers would not suddenly be confronted with a
hda->sda switch.

I have not really followed Debian kernels regarding this, but currently I
think we basically just have both IDE and ATA drivers enabled. Correct?

Are any of those early "avoid duplicate PCI ID" patches still active?

Do we have any idea yet how this is going to be handled/documented for
upgrades?

On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> * Pierre Habouzit (madcoder@debian.org) [080707 19:48]:
> > Changing kernel at this point of the release would be too destructive,
> > so unless there is a big fat problem in the .25 that the .26 should fix
> > and is unbackportable (does such a beast even exist ?) I'm rather
> > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > to hppa.
> >
> > Disclaimer: it's my own opinion, I did not check what other Release Team
> > member think about this.
>
> I agree with you, at least with my current informations.

please read the changelog trunk on all the 2.6.26 fixes.

we have allways stated that .26 will be the release kernel.
i don't understand why this would come as a surprise.

.26 is to be released in a week, which is early enough to
prepare all stuff including testing migration.

--
maks


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Jul 08, 2008 at 06:59:40AM +0000, maximilian attems wrote:
> On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > * Pierre Habouzit (madcoder@debian.org) [080707 19:48]:
> > > Changing kernel at this point of the release would be too destructive,
> > > so unless there is a big fat problem in the .25 that the .26 should fix
> > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > > to hppa.
> > >
> > > Disclaimer: it's my own opinion, I did not check what other Release Team
> > > member think about this.
> >
> > I agree with you, at least with my current informations.
>
> please read the changelog trunk on all the 2.6.26 fixes.

Huh, that's not really our work, you as the maintainer should help us
understand why we would like to deal with 3 months of FTBFS *right now*.
Not to mention the libata changes fjp talks about, that would probably
break many upgrades and for which there is no known solution.

> we have allways stated that .26 will be the release kernel.

The sole mail from the kernel team that I can find is[0]. We've seen
no updates from you since AFAICT. Given the content of the mail, and its
age, I don't see how we can know that.

> I don't understand why this would come as a surprise.

I'll start with reminding you that the toolchain is frozen and that
the kernel is part of it.

Now could you explain how changing kernel for a new upstream, with the
well known fact that one needs to wait for the .2/.3 to have a decent
working kernel (IOW in at least 2/3 weeks after the release) is not a
disruptive change[1]? Add testing migration to that, plus tied
transitions, then I expect a really good rationale from you to explain
why a 6-8 weeks delay in the toolchain freeze (IOW in the release
process) is acceptable and needed[2].

The fact that you're unable to understand that is quite worrying.


[0] http://lists.debian.org/debian-release/2007/04/msg00189.html

[1] e.g. have you done full scale archive rebuilds to show that a new
linux-libc-dev won't at least cause dozens of FTBFS like the
2.6.25 did ?

[2] and I'm pretty sure the d-i crew has alike reservations.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org

maximilian attems <max@stro.at> 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: otavio@debian.org 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 debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote:
> On Tue, Jul 08, 2008 at 06:59:40AM +0000, maximilian attems wrote:
> > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > > * Pierre Habouzit (madcoder@debian.org) [080707 19:48]:
> > > > Changing kernel at this point of the release would be too destructive,
> > > > so unless there is a big fat problem in the .25 that the .26 should fix
> > > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > > > to hppa.
> > > >
> > > > Disclaimer: it's my own opinion, I did not check what other Release Team
> > > > member think about this.
> > >
> > > I agree with you, at least with my current informations.
> >
> > please read the changelog trunk on all the 2.6.26 fixes.
>
> Huh, that's not really our work, you as the maintainer should help us
> understand why we would like to deal with 3 months of FTBFS *right now*.
> Not to mention the libata changes fjp talks about, that would probably
> break many upgrades and for which there is no known solution.

right so the 2.6.26 summary:
* closes 50 bugs on upload (mostly 2.6.25 regressions)
* has upstream coordination with xen and openvz
* is the first version with kernel debugger
* much better laptop support (wireless, uvc,..)
* kvm ported to IA64, PPC and S390

> > we have allways stated that .26 will be the release kernel.
>
> The sole mail from the kernel team that I can find is[0]. We've seen
> no updates from you since AFAICT. Given the content of the mail, and its
> age, I don't see how we can know that.

right to debian-release that was the last time we got asked to give a
statement. in discussion on d-kernel and with d-boot we allways stated
to work on 2.6.26 for Lenny.

> > I don't understand why this would come as a surprise.
>
> I'll start with reminding you that the toolchain is frozen and that
> the kernel is part of it.
>
> Now could you explain how changing kernel for a new upstream, with the
> well known fact that one needs to wait for the .2/.3 to have a decent
> working kernel (IOW in at least 2/3 weeks after the release) is not a
> disruptive change[1]? Add testing migration to that, plus tied
> transitions, then I expect a really good rationale from you to explain
> why a 6-8 weeks delay in the toolchain freeze (IOW in the release
> process) is acceptable and needed[2].

a freeze exception for releasing debian with an uptodate and tuned
system is worth.

> [1] e.g. have you done full scale archive rebuilds to show that a new
> linux-libc-dev won't at least cause dozens of FTBFS like the
> 2.6.25 did ?

there are statements from waldi and vorlon to consider the 2.6.25
linux-libc-dev status as frozen.


kind regards

--
maks

ps fjp is wrong we don't switch to pata and are not forced to do
so for 2.6.26, no idea, where he got that idea.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org