From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQFOX-0003qs-Hq for qemu-devel@nongnu.org; Tue, 15 Nov 2011 04:33:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQFOR-0001RD-V5 for qemu-devel@nongnu.org; Tue, 15 Nov 2011 04:33:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQFOR-0001Qw-O3 for qemu-devel@nongnu.org; Tue, 15 Nov 2011 04:33:27 -0500 Message-ID: <4EC232A1.9080703@redhat.com> Date: Tue, 15 Nov 2011 10:36:33 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1321114074-3681-1-git-send-email-aliguori@us.ibm.com> <4EC18349.20203@us.ibm.com> In-Reply-To: <4EC18349.20203@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] migration: add a MAINTAINERS entry for migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, quintela@redhat.com Am 14.11.2011 22:08, schrieb Anthony Liguori: > On 11/14/2011 11:40 AM, Juan Quintela wrote: >> Anthony Liguori wrote: >>> I think this is an accurate reflection of the state of migration today. This >>> is the second release in a row where we're scrambling to fix a critical issue >>> in migration. >> >> We need to make our mind about it. > > Ultimately, we need to make migration a priority. That's what I'm trying to do > here. When you make everything a priority, being a priority doesn't have much of a meaning any more. Our current priorities are changing the entire device model, the monitor, migration, turning the block layer upside down - what's left? Okay, maybe vvfat and slirp. > The first step is to be open about the state of migration today. I personally > don't have the bandwidth to invest a lot of effort in migration, but I can > invest time in trying to find more people to work on migration, and help put > together a proper roadmap. > > We need to outline and document what we support and what we don't support. We > need to invest in a test infrastructure. We need a roadmap that we can > reasonably execute on. In short, we need to turn migration into a first class > subsystem. > > It's not about any single person or any single patch series. It's about > deciding that migration is an important feature and deserves more focus and > attention. I don't doubt that everyone will agree with this. The harder question is who should concentrate less on which other feature to have time to spend for migration. Kevin