[libvirt] libvirt and the lowest common denominator

[John Levon]

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