On Thu, Apr 10, 2008 at 04:19:47PM -0400, Cole Robinson wrote:
John Levon wrote:
(I know I've whined before but it would be awfully nice to have some-one step up and update the schema: then it would be possible to insist all such changes update the schema too.) Yes, but that doesn't excuse developing these extensions in private and then just dumping them on the list as a final solution.
That's hardly fair. There's a big 'RFC' in the subject and Ryan explicitly said they weren't ready. Eunice has been responding to all your comments. Who's been talking of "final solutions"?
To quote Eunice:
I don't think the first option (to change the LDoms Manager XML format to be based on the libvirt XML format) is a feasible one since LDoms has been released public and some tools/applications are already based on the LDom Manager's XML interfaces.
How can that be interpreted as anything but 'final'? An RFC is not about implementation details, it should be about the big picture. Already shipping a supported product based on an XML format that was not discussed upstream prior is about as final as it gets, IMO.
Yes, that's exactly the point I was attempting to make. The fact that there is a shipped LDoms 'libvirt' release is a huge problem, because it has now diluted the value of libvirt, because it is not compatible with the official libvirt. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|