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 ([EMAIL PROTECTED]) [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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
