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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list