Re: Selection of kernel for Lenny
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.
Reply to: