Re: [libvirt] libvirt and the lowest common denominator
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