On Mon, Feb 09, 2009 at 04:54:51PM +0000, Daniel P. Berrange wrote: > > 2. I'd like to hear a rationale for this rule. > > The number one rule is not to fork codebases in incompatible ways. Agreed. Thankfully, we haven't done that. > Adding new features to a particular version of Xen and not making any > effort to send them back upstream is needlessly forking the code. A separate matter, but yes, efforts should be made to upstream things, I agree. I think if you look at the xen-devel history you'll see plenty of that. > > 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 ? Certainly not. However, moving to a new Xen version takes a very long time. The release quality is generally very poor, and combined with a Linux focus, it often takes weeks of work to move major versions. This is why we're still on 3.1.4. Practically, we *cannot* follow upstream directly. We will have enhancements; we'll have fixes; we'll disable completely broken code like the XenAPI implementation. This doesn't make us "divergent". > > 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. This is very far away from what I consider maintenance. > 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 I'm not arguing an attempt shouldn't be made to upstream this particular patch. My points cover a wider issue. > 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. It wouldn't be ideal, thankfully I don't expect that to happen. But even if it did: 72 #ifdef WITH_RHEL5_API 73 #define XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU 0 74 #define XEND_CONFIG_MIN_VERS_PVFB_NEWCONF 2 75 #else 76 #define XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU 3 77 #define XEND_CONFIG_MIN_VERS_PVFB_NEWCONF 3 78 #endif This is exactly the same situation: you have a forked version of upstream that requires special handling. > > 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. There is no different manner without dropping xend altogether. You're perfectly happy for any stupid decision made by XenSource to negatively impact the libvirt project? Wow. There's no point having this argument if you're willing to throw away innovations. We won't stand for brokenness because of some bizarre policy, sorry. > > 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. 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. john -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list