From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCU3r-0006LJ-47 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 02:09:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCU3q-0006L5-Jr for qemu-devel@nongnu.org; Tue, 16 Dec 2008 02:09:42 -0500 Received: from [199.232.76.173] (port=53044 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCU3q-0006L2-GE for qemu-devel@nongnu.org; Tue, 16 Dec 2008 02:09:42 -0500 Received: from mta23.gyao.ne.jp ([125.63.38.249]:53878 helo=mx.gate01.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCU3p-0003Br-PE for qemu-devel@nongnu.org; Tue, 16 Dec 2008 02:09:42 -0500 Date: Tue, 16 Dec 2008 16:07:43 +0900 From: Paul Mundt Subject: Re: [Qemu-devel] [PROPOSITION] SH4 workflow improvement Message-ID: <20081216070743.GA27495@linux-sh.org> References: <20081206120741.GB2977@game.jcrosoft.org> <200812091804.mB9I4Cxf025339@smtp11.dti.ne.jp> <20081210050217.GC27356@linux-sh.org> <49413EB1.2030200@juno.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49413EB1.2030200@juno.dti.ne.jp> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jean-Christophe PLAGNIOL-VILLARD , Nobuhiro Iwamatsu , Aurelien Jarno On Fri, Dec 12, 2008 at 01:24:17AM +0900, Shin-ichiro KAWASAKI wrote: > Paul Mundt wrote: > >It makes sense to have a staging tree where stuff can be queued up, > >tested, and reworked until it is merged upstream. For the development of > >new features, it is helpful to prevent fragmentation. We've already seen > >this with at least 3 different people working on CF at basically the same > >time without any knowledge of what was going on, this is something we > >want to avoid. > > Hm, staging tree seems to have two roles. > - Make it easy to review/test qemu-sh patches, > so that high quality patches are sent to upstream. > - Avoid work duplications among qemu-sh developers. > And the drawbacks are, > - Might discourage merge to upstream. > - Messy to send patch both upstream and staging. > I don't think any of those drawbacks apply, that is precisely why it is a "staging" tree. The idea is that people do all of their development against QEMU SVN as they do now, and the staging tree simply keeps track of them. The staging tree is mostly a benefit for users looking for the complete available state of development for SH while providing a stable point of reference for developers to make sure there is no overlapping work. After thinking about this some more, I have decided against a git tree, mostly since having a forked git tree encourages people to do development there instead of on SVN, and it is less obvious at first glance what is provided by the tree and how badly it deviates from the SVN HEAD. Nothing in the staging tree should be long-lived, and the only stuff hanging around there are patches that are destined for merging but might still be in need of wider testing, some incremental changes, etc. I expect patches to be dropped from the staging tree just as quickly as they are applied, so it should never be anything completely unwieldly, and certainly not a fork. You should not confuse "staging" with "development fork", they are wholly unrelated concepts, the latter of which I don't believe anyone is interested in. > Even though I'm not yet sure the staging tree will work fine or not, > I'll try to use the repository 'http://repo.or.cz/w/qemu/sh4.git' > to push my patches. > # I'm going to work for U-Boot trouble on qemu-sh. > I would prefer that you just send them to the list as usual rather than fragmenting development. I don't think anyone really wants to track multiple trees to see who is doing what. If it hasn't been posted to the list, it shouldn't be in the tree, either. Anyways, I have converted the aforementioned URL to be a quilt series, there is some further documentation in there. I will announce it to the linux-sh list later today. It already contains outstanding patches from Vladimir, Yoshii-san, and Jean-Christophe.