Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/07/2011 05:57 AM, Ingo Molnar wrote:
> * Pekka Enberg<address@hidden>  wrote:
>
> > On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
> > > > It's not just about code, it's as much about culture and development process.
> > >
> > > Indeed.  The BSDs have both kernel and the base system in a single
> > > repository.  There are probably good reasons for (and against) it.
> > >
> > > In Linux we don't have that culture.  No tool (except perf) lives
> > > in the kernel repo.  I fail to see why kvm-tool is that much
> > > different from udev, util-linux, iproute, filesystem tools, that
> > > it should be included.
> >
> > You seem to think perf is an exception - I think it's going to be
> > the future norm for userspace components that are very close to the
> > kernel. That's in fact what Ingo was arguing for when he suggested
> > QEMU to be merged to the kernel tree.
>
> Yep, and the answer i got from the Qemu folks when i suggested that
> merge was a polite "buzz off", along the lines of: "We don't want to
> do that, but feel free to write your own tool, leave Qemu alone."

At least it was polite :-)

> Now that people have done exactly that some Qemu folks not only have
> changed their objection from "write your own tool" to "erm, write
> your own tool but do it the way *we* prefer you to do it" - they also
> started contributing *against* the KVM tool with predictable, once
> every 3 months objections against its upstream merge...
>
> That's not very nice and not very constructive.

I think it's fair to have an objection to upstream merge but I think these 
threads are not terribly constructive right now as it's just rehashing the same 
arguments.

I've been thinking about the idea of merging more userspace tools into the 
kernel.  I understand the basic reasoning.  The kernel has a strong, established 
development process.  It has good infrastructure and a robust hierarchy of 
maintainers.

Good infrastructure can make a big difference to the success of a project. 
Expanding the kernel infrastructure to more projects does seem like an obvious 
thing to do when you think about it in that way.

The approach other projects have taken to this is to form a formal incubator. 
Apache is a good example of this.  There are clear (written) rules about what it 
takes for a project to join.  Once a project joins, there's a clear governance 
structure.  The project gets to consume all of the Apache infrastructure resources.

Other foundations have a release cadence to ensure that multiple components form 
a cohesive individual release (oVirt).

I think you are trying to do this in a more organic way by just merging things 
into the main git tree.  Have you thought about creating a more formal kernel 
incubator program?

Regards,

Anthony Liguori