On Mon, Feb 09, 2009 at 12:18:17PM -0500, John Levon wrote: > > > 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". Adding enhancements is what causes the problems & make it divergent, because the way you add a enhancement for feature XYZ is not guarenteed to be the way xen-unstable.hg does an enhancement for the same new feature XYZ. Bug fixes are fine, turning off unneccessary / broken bits is fine, but adding new features that are not first upstream causes problems. > > > 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. Likewise, but the fact remains that patches are posted & accepted into the codebase for issues like the ones being discused with device unplug of NICs. > > 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. 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 available in upstream xen-unstable.hg tree. We do not add new features which are RHEL-5 only because that is not sustainable. This piece of code from libvirt you quote is not implementing any new features, it is merely turning on an existing feature. So that something that is upstream from 3.1.0 or later, is now also used when talking to Xen 3.0.4. This is why new features should be *backports* of existing stuff in upstream xen-unstable.hg - it means there only needs to be one functional implementation of the code in libvirt, which then only has to be turned on for corect version. Most of the features don't even need code like the lines you quoted above, becuse they 'just work' when backported from upstream. > > > 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. I didn't say I would be happy, just that things don't always work out as expected & sometimes need changing to meet the needs of the broader community, instead of just my our needs. > > > 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. 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. 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