On Mon, Feb 09, 2009 at 10:39:55AM -0500, John Levon wrote: > > I wanted to bring this topic out of a patch review thread. > > Dan recently stated that only patches that use "upstream" facilities are > acceptable, meaning the xend delivered by XenSource. I'd like to make a > few points on this note: > > 1. I'd like to hear from the other core maintainers if they agree with > this rule. > > 2. I'd like to hear a rationale for this rule. The number one rule is not to fork codebases in incompatible ways. Adding new features to a particular version of Xen and not making any effort to send them back upstream is needlessly forking the code. This ripples into libvirt, because if upstream then adds the same feature but implements it in a different way, libvirt now has to satisfy two conflicting implementations, which hurts long term maintainability of our own code. > 3. The Sun repository *is* the upstream for xend on Solaris for a number > of reasons: > > a. The 3.1.x series is only maintained by us, there is no other 3.1 upstream > > b. The XenSource upstream does not, and cannot, work on Solaris Are you in essence saying that long term you don't intend to follow the new Xen releases, and Solaris XenD should be considered a divergant fork long term ? Hopefully this isn't the case, but it'd mean we have to cope with the one libvirt Xen driver trying to serve & satisfy two different masters at once. > c. XenSource have no interest in xend at all and it's effectively > unmaintained (with the exception of Novell I think). While they may not have been doing much active new development work, they have still been accepting patches posted on xen-devel from a variety of sources, and doing new maintainence releases of the code. > 4. I've seen stated a number of times that libvirt is designed to avoid > becoming a lowest common denominator interface. I cannot reconcile that > claim with this rule: all xend implementations must apparently be the > same, and no enhancements are allowed. This is not about lowest common denominator. It is about not needlessly forking code bases when adding new capabilities. The network device unplug enhancement is a perfect example. This is not Solaris specific in any way. If this were sent upstream and merged it serves to benefit all users of Xen, and means libvirt only has one implementation to worry about. If it is not sent upstream, and we put the Solaris speciifc code in place, and upstream then implements it in a different way, libvirt now has to carry 2 different impls of network unplug code. This is really not nice. > 5. This rule further restricts innovation in that XenSource must agree > to any changes. This has a rather obvious chilling effect. The distro > type/variant recording changes are a perfect example: this is essential > information, and recording it in xend was pre-NAKed by XenSource a long > time ago. IMHO, that's life in open source development. Sometimes things get nack'd and have to be implemented in a different manner to be acceptable to all members of the upstream community. Having everyone go off and do their own implementation of features when upstream reject them, is just not long term sustainable to the downstream users of that project being forked. > 6. As a thought experiment: if someone re-wrote xend in C, what then? Is > that upstream, or not? In case it's not clear, all of Sun's Xen changes > are open source and easily available. It would likely be a totally different product, requiring a from-scratch libvirt driver to support it. FWIW, we already have this scenario in the form of XenAPI + XenEnterprise server, which ditched current Xen RPC api that we use. If we added XenAPI support to libvirt, I expect it would be a completely new driver, whose code is independant of the existing libvirt Xen driver code. This would actually be an easier situation, because there'd be an explicit clean division between the implementations, and (within the confines of the libvirt API semantics & XML format) can evolve independantly of each other, not having to worry about one causing trouble for the other & vica-verca. The problem we have currently is harder two reconcile, because it involves trying to make 1 driver work with 2 potentially divergent projects. > 7. Any change that involves *incompatibility* is clearly different, and > IMHO not acceptable. This is only about changes that in no way > negatively affect behaviour with an upstream Linux xend. You need to consider future incompatability as well as any current incompatability. ie the scenario where you implement feature XYX one way, and the next upstream release implements it a completely different way. libvirt now has to carry 2 different implementations of the same code indefinitely, or choose to not support one of the forks. Neither is a good option really. > 8. I hope it's clear to everyone that I'm motivated to merge changes > upstream wherever feasible. I'm not seeking some kind of get-out clause > from being a responsible maintainer. > > 9. Practically, we will have to carry these changes in our libvirt no > matter what. I'd rather not. > > 10. I would note that Red Hat own the upstream for the code they care > about, thus this rule can only cause trouble for other people. Red Hat / Fedora always follow the rule of getting patches accepted by upstream Xen developers, despite fact that RHEL-5 is on ancient XenD 3.0.3, new features for 5.1, 5.2, 5.3, updates are all required to be upstream in xen-unstable first, and then backported. Likewise when we need new features for QEMU/KVM, we have to work with those development communities to get them to accept the required changes in QEMU codebae. On many occassions I've had code rejected outright, or rejected needing a re-write. The same rules for including new code in the QEMU driver of libvirt - if it needs a new QEMU command line argument, or monitor command, then that must be present in upstream QEMU/KVM codebase first. KVM is actually rather a PITA in some cases, because it has forked QEMU and added features, which then got re-implemented in QEMU. We got horribly burned by this in the case of migration whose command line syntax was changed. We should never have added support for that in libvirt while it was still in KVM only because the long term pain it caused outweighs the short term gain it had. NB, once a feature is upstream, then it *is* acceptable to backport to an existing release, because at that point you know that the patch will be short-lived until the next code rebase & is unlikely to be changed in an incompatible way. And downstream users of that feature (such as libvirt) only have one implementation they have to worry about. Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list