From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNP4Z-0008TP-6R for qemu-devel@nongnu.org; Mon, 07 Nov 2011 08:17:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNP4T-0001d9-5m for qemu-devel@nongnu.org; Mon, 07 Nov 2011 08:17:11 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:46972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNP4T-0001d2-3H for qemu-devel@nongnu.org; Mon, 07 Nov 2011 08:17:05 -0500 Received: by ggnp2 with SMTP id p2so1697936ggn.4 for ; Mon, 07 Nov 2011 05:17:04 -0800 (PST) Message-ID: <4EB7DA4C.3080504@codemonkey.ws> Date: Mon, 07 Nov 2011 07:17:00 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <20111107115734.GA30222@elte.hu> In-Reply-To: <20111107115734.GA30222@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ingo Molnar Cc: Pekka Enberg , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , Alexander Graf , qemu-devel Developers , Blue Swirl , Pekka Enberg , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Linus Torvalds , Gerd Hoffmann On 11/07/2011 05:57 AM, Ingo Molnar wrote: > > * Pekka Enberg 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