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

Re: Selection of kernel for Lenny



On Tue, Jul 08, 2008 at 03:27:17PM +0200, Pierre Habouzit wrote:
> On Tue, Jul 08, 2008 at 12:43:49PM +0000, maximilian attems wrote:
> > 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)
> 
>   I'm really afraid with the number of bugs it'll open though.

upstream has much better control of it thanks to kernelopps,
random .config boot tests and regression handling.
 
> > * has upstream coordination with xen and openvz
> 
>   Does this mean that dom0 will work with .26 ? If yes, then maybe .26
> is really worth considering. If not, this is quite moot.

we get snapshot working, that is *important* for guest.
otherwise you would not be able to migrate your debian guest.

and please don't dismiss openvz, which is the new emerging namespace
solution that has more features then vserver and works actively on
upstream merge. we have worked together with openvz devs to have
.26 openvz images.
 
> > * is the first version with kernel debugger
> > * much better laptop support (wireless, uvc,..)
> > * kvm ported to IA64, PPC and S390

of course a lot of fixes and forgot to mention the
* Read-only bind mounts

which can come in really handy for chroots and buildd.
 
> > > > 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.
> 
>   Well, we did asked for updates from core teams in our mails to d-d-a
> numerous times without our prior nagging, which was clearly meant to
> avoid this kind of communication issues.
> 
>   For the rest I assume the release team will have to discuss things a
> bit further.

okay sorry for having not catched that.
 
> > >   [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.
> 
>   Well, that's a sine qua non condition. L-L-Dev breakages are horrible,
> and we just cannot aford one. It does not mean that I consider .26 to be
> a clever idea right now, but a l-l-d breakage would be a plain no-go.

sure fully agreeed.

-- 
maks


Reply to: