From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MljRU-0003BE-17 for qemu-devel@nongnu.org; Thu, 10 Sep 2009 09:12:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MljRP-00039Q-CQ for qemu-devel@nongnu.org; Thu, 10 Sep 2009 09:12:03 -0400 Received: from [199.232.76.173] (port=53026 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MljRP-00039K-3i for qemu-devel@nongnu.org; Thu, 10 Sep 2009 09:11:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19103) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MljRO-0006uD-Lf for qemu-devel@nongnu.org; Thu, 10 Sep 2009 09:11:58 -0400 Date: Thu, 10 Sep 2009 10:11:48 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: QEMU patch management Message-ID: <20090910101148.1af158bc@doriath> In-Reply-To: <20090910125109.GB14681@1und1.de> References: <20090902074905.GB25711@chrom.inf.tu-dresden.de> <20090909121817.GA21997@chrom.inf.tu-dresden.de> <4AA7A6EC.10907@codemonkey.ws> <20090910070336.GD3351@amit-x200.redhat.com> <20090910075644.GA6769@1und1.de> <20090910100804.GA7992@amit-x200.redhat.com> <20090910084713.41dae0b4@doriath> <20090910120121.GB27014@amit-x200.redhat.com> <20090910092938.431a3622@doriath> <20090910125109.GB14681@1und1.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Reimar =?UTF-8?B?RMO2ZmZpbmdlcg==?= Cc: qemu-devel@nongnu.org On Thu, 10 Sep 2009 14:51:09 +0200 Reimar D=C3=B6ffinger wrote: > On Thu, Sep 10, 2009 at 09:29:38AM -0300, Luiz Capitulino wrote: > > On Thu, 10 Sep 2009 17:31:21 +0530 > > Amit Shah wrote: > > > It can easily be done. The process has to scale considering the number > > > of submissions we're seeing. > >=20 > > I agree, with more maintainers QEMU would evolve a lot faster and I th= ink > > this is becoming an issue. > >=20 > > On the other hand I don't think we will have them by distributing > > responsibilities, those interested should setup a tree and > > start collecting patches. >=20 > You're saying that just like that, but if you just set up your own tree, > at least if you are not a git guru you end up with the same mess as I > have now: > The official qemu git tree, Stefan Weil's git tree and the kvm tree, all > have slightly different eepro100 code and for each one I have to do > merges since I have no idea which path has a chance to get patches > accepted (since after all I got no response anywhere). This is a sightly different problem that is related to the fact that qemu is forked. > For me that is simply too much effort (I am after all a FFmpeg/MPlayer de= veloper > in the first place) and I'll probably just drop all the non-trivial > changes I made because they have a too high merging effort. Not sure if this is what you meant but, having different trees for different subsystems is one of the best ways to get large scale development and that's how git was designed to work.