From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm repository unification Date: Tue, 20 Mar 2007 16:38:20 +0200 Message-ID: <45FFF1DC.2050708@qumranet.com> References: <45FFCFD7.5000107@qumranet.com> <200703201420.10139.arnd@arndb.de> <45FFE5AB.3030501@qumranet.com> <45FFEB6B.4090301@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <45FFEB6B.4090301-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: >> > > I think a single repository with libkvm and a QEMU and kernel patch > queue (quilt or mq, it doesn't matter to me) would be best. > > Patches in the main queue would get folded upstream quickly > (hopefully). Devs would submit new patches that you may choose to > either add to the queue or fold an existing patch. > > I actually find that it's easier to do merging with a patch queue than > by directly committing. > One issue I see with it is that it's impossible to go back in history, as the reference point to which patches are applied changes in time. Perhaps I could record the nearest git tag in a version controlled file, and the build scripts would checkout that tag from an associated kernel git repo. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV