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
