Re: Fixes to Etch kernel for use in a Xen domain 0

[dann frazier <dannf@debian.org>]

On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
> On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> > I'm not aware of any well-formed consensus yet - though there are
> > several ideas. I'll caveat this by saying I don't follow Xen
> > development at all, and didn't participate in the previous thread
> > about this (very busy at the time), but I do think the approach that
> > would be best for our users is to ship a 2.6.18-based kernel in
> > lenny - aka, Bastian's Option 5:
> >   http://lists.debian.org/debian-devel/2008/07/msg00476.html
> 
> What is the problem with Option 4?

My two concerns with that are:
 * Dropping support for a package in a stable release (which we
   currently only do due to unforeseen circumstances) and
 * forcing users to upgrade to a new upstream version within a stable
   release.

> > Since its neither a >= important bug for etch, nor obviously safe for
> > existing installs, I don't think it'd be an option for 'etch'.
> 
> It is safe for existing installs. It only adds a new parameter which
> changes the behavour if set.

Well, its not as straightforward as if (opt) { new_behavior; }, but it
is probably something reasonable to verify via code review and
testing. However, it is still a feature change. Certainly, if the
project decides that we need to use the etch kernel directly in lenny
(and not a separate lenny-specific 2.6.18 branch), then I think its
reasonable to argue for an exception for that technicality - but we're
not there yet.

> > > If this is unacceptable (probably?) then are there any other
> > > options/plans/ideas for providing an updated 2.6.18 domain 0 kernel? I
> > > hear Bastian has a repo somewhere?
> > Yeah, he maintains a branch under people/waldi, iirc. Not sure where
> > the builds are though.
> 
> deb http://kernel-archive.buildserver.net/debian-kernel/waldi/xen-extra all main
> 
> Bastian
> 



-- 
dann frazier