From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S60Oa-000263-DA for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:02:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S60OD-0003PH-9l for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:02:11 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:60088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S60OD-0003Ow-5o for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:01:49 -0500 Received: by ggnj2 with SMTP id j2so997504ggn.4 for ; Fri, 09 Mar 2012 06:01:47 -0800 (PST) Message-ID: <4F5A0D49.60200@codemonkey.ws> Date: Fri, 09 Mar 2012 08:01:45 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F582EDB.1040608@redhat.com> <4F58B5CB.8040503@codemonkey.ws> <4F58CDEA.2020506@redhat.com> <4F59010C.2060105@codemonkey.ws> <4F5909B3.4080405@redhat.com> <4F590BD7.6030605@codemonkey.ws> <4F5913F3.3040503@redhat.com> <4F591EB4.1090300@codemonkey.ws> <4F5A076E.9040904@redhat.com> In-Reply-To: <4F5A076E.9040904@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Lucas Meneghel Rodrigues , Cleber Rosa , QEMU devel , Ademar Reis On 03/09/2012 07:36 AM, Paolo Bonzini wrote: > Il 08/03/2012 22:03, Anthony Liguori ha scritto: >>>> >>>> >>>> Herein lies the problem. You forgot and it's your proposal :-) >>> >>> Ok, fair enough :) But still, qemu-jeos points out to external >>> repositories, >>> just as much as buildroot. It seems to me that the whole point about FSF >>> requiring the source to be under your control is no longer valid here. >> >> There aren't qemu-jeos binaries on qemu.org. There won't be until I >> mirror the git repos. >> >> It's the infrastructure that matters here. Submodules provides a nice >> infrastructure to handle all of this and minimizing the external >> components makes the whole thing much more manageable. > > How do you handle out-of-tree patches with submodules (as is the case > when working on new code)? It's very easy to update .gitmodules to point to a different tree on your local system and then update the ref to a local commit. So from a development perspective, it's simple. The harder question is what to do about qemu-test HEAD on qemu.org Maintaining downstreams or patches is just too much work IMHO. I think for qemu.org, we simply have to use Linus or Avi's tree and simply live with the consequences. We could open up another tree on qemu.org with patches if someone was willing to maintain it but I think that's a bad strategy to take. But it's a possibility if this really becomes a problem. > > You want to require tests in order to commit to qemu, but this (for > tests where using qtest is not feasible for any reason) requires all > drivers to be upstream and accessible to qemu-jeos. We're really just talking about virtio here, no? Maybe we can convince Rusty to have a proper virtio-next.git... > Perhaps for this it would make sense to associate a qemu-jeos commit id > with an upstream commit (from upstream) + a quilt patch queue. > > But there's also the problem of embedded devices whose toolchain is not > available upstream at all, so you'd need to import those separately and > somehow add a different submodule. I think this ends up being outside the scope of qemu-test. Perfect is the enemy of good here. Regards, Anthony Liguori > Paolo