Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> A private mail to Fabrice may be in order, if you're interested in
> core maintenance.  Try to involve KVM folks too, that way lies sanity.

Quite.  I'll mail Fabrice - but generally I prefer to do things in
public where possible because it can avoid some political problems.

> Given the commercial tension at present between Citrix (Xen) and
> Qumranet (KVM) perhaps neither of you should be the sole primary
> maintainer of core systems :-)

I think it's important that we get a consensus about the architecture
and have a healthy approach to deciding what to do about technical
questions where we disagree.  I certainly wouldn't want to do anything
that didn't have reasonably broad support.  So I think that calls for
an open approach and open discussion.

I've generally found that it's quite possible for people whose
employers have in some sense competing interests, to work well
together improving code that they are all depending on.  I think
provided we can avoid trying to block each other's contributions out
of spite there shouldn't be a problem.

I think the most important thing for any new commiter is to have a
clear shared understanding of what kind of commits, and when, are
acceptable.

> Andreas Färber wrote:
> > Xen (the whole ecosystem) is indeed very dependent on Qemu and the
> > divergence between our tree and the upstream one is far too great.
> > Many of our changes are entirely applicable to upstream.
> 
> I agree, and the same applies to KVM's QEMU branch, but perhaps that
> diverges less than Xen's.

I've had a brief look at it but I haven't a clear idea of the amount
of divergence in the KVM branch.

> Good plan.  I suggest not just reducing code divergence, but
> clarifying QEMU's future vision with Fabrice would help too.

Yes.

Jan Kiszka writes ("[Qemu-devel] Re: An organizational suggestion"):
> Another remark: If potential new maintainers should be affiliated with
> any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
> would be happy to see a public agreement beforehand on the general
> architectural roadmap to cover those two requirement domains (+ the one
> of KQEMU) in the future QEMU design. It would be bad for this project if
> one side overrules the other via the (non-technical) preference of a
> maintainer. Really, that's nothing against Ian personally or against
> Xen/Citrix, the same would apply to KVM/Qumranet!

Oh, certainly I don't think I would want to be in that position.

I'm not sure we need an `architectural roadmap' agreed in advance; it
might be better to discuss individual architectural questions one at a
time.

We should probably start with some easy tasks - for example,
straightforward and uncontroversial improvements to the various device
models (of which we have some languishing in our Xen branch).

The Xen- and KVM-specific changes are more complicated but I think we
should be able to agree at the very least interfaces, hooks, or coding
conventions which allow our respective changes to become much less
intrustive.

Ian.