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

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

 



On 11/07/2011 05:57 AM, Ingo Molnar wrote:

* Pekka Enberg<penberg@xxxxxxxxxxxxxx>  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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux