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

Re: [libvirt] libvirt and the lowest common denominator



On Tue, Feb 10, 2009 at 10:21:11AM +0000, Daniel P. Berrange wrote:

> > This is exactly the same situation: you have a forked version of
> > upstream that requires special handling.
> 
> This is missing the point I have been trying to make. RHEL-5 is using the
> old Xen 3.0.3 codebase for XenD. We have added a large number of features
> to this over time. *ALL* of these features are things that are already

I don't think I am missing that point. I don't see much difference
between the two cases, that's all.

> > > It would likely be a totally different  product, requiring a from-scratch
> > > libvirt driver to support it.
> > 
> > Let's see. Your policy has now led us to the situation where to enable
> > storing of essential debug information, we have to duplicate several
> > thousand lines of C code.
> 
> Or work to get the neccessary feature upstream so it be used by libvirt
> and all other users of XenD without everyone having to re-invent it in
> their private code trees.

Again, there is no work that can be done: it's forever NAKed. It's
impossible to upstream it.

It seems you are willing to let XenSource dictate what functionality
libvirt is able to provide for Xen users. I care about improving the
system even if XenSource's whims dictate otherwise, and it doesn't seem
like we can reach agreement on this point. It's a pity our goals for
what libvirt is all about aren't in agreement.

regards,
john


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