[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] libvirt and the lowest common denominator

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.

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

c. XenSource have no interest in xend at all and it's effectively
   unmaintained (with the exception of Novell I think).

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.
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.

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.

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.

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.

My personal opinion, not Sun's.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]