On Wed, Aug 10, 2011 at 03:49:25PM +0100, Jan Beulich wrote:
> >>> On 10.08.11 at 16:37, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> > On 10/08/2011 14:58, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> >
> >>>>> On 10.08.11 at 15:45, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >>> On Wed, 2011-08-10 at 12:40 +0100, Pasi Kärkkäinen wrote:
> >>>> Also: Shouldn't this be against upstream Linux 3.x these days, aswell,
> >>>> now when both blkback and blkfront are upstream?
> >>>
> >>> Yes, please.
> >>>
> >>> Ideally we would insist that patches to those classic-Xen trees which
> >>> are still somewhat maintained be sent to upstream first where applicable
> >>> (i.e. only accept "backports" or classic-Xen specific bug fixes).
> >>
> >> Ideally yes. But that's not generally feasible, at least not always. For
> >> instance, I'm glad if I can keep on top of all the things needed for our
> >> kernels and hypervisors, and I would at best find time to compile test
> >> code for pv-ops. But with only that I certainly shouldn't really submit
> >> anything...
> >
> > I suspect that by now you are the only direct consumers of 2.6.18-xen. Is
> > there really any benefit to keeping the public tree now? Only you commit to
> > it; I expect only you directly inherit from it (others might indirectly, I
> > accept). I really don't think we should be tempting anyone else to actually
> > *use* it as is. Hence my conclusion we could just delete the damn thing.
>
> It's convenient to me, as this way I don't have to deal with a rapidly
> growing set of individual patches. But if the tree went dead (I wouldn't
> really want to see it deleted, so one can still use it for archaeological
> purposes), we would certainly survive.
>
How about retiring the linux-2.6.18-xen.hg and create a new
linux 2.6.32 based (git?) tree for the SLES11 and XCP/XenServer
xenlinux based classic kernels?
Those two kernel trees are probably still maintained for quite some time,
so wouldn't that be the easiest way? (until everyone is using pvops dom0)
Does that make any sense?
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|