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