From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7rsg-0000VA-Im for qemu-devel@nongnu.org; Sun, 25 Sep 2011 12:48:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7rsf-0001Lr-HO for qemu-devel@nongnu.org; Sun, 25 Sep 2011 12:48:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7rsf-0001Ln-AF for qemu-devel@nongnu.org; Sun, 25 Sep 2011 12:48:41 -0400 Message-ID: <4E7F5B62.1090307@redhat.com> Date: Sun, 25 Sep 2011 19:48:34 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E7A828A.3030404@codemonkey.ws> <4E7F366F.9060501@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On 09/25/2011 07:36 PM, Blue Swirl wrote: > On Sun, Sep 25, 2011 at 2:10 PM, Avi Kivity wrote: > > On 09/24/2011 11:05 AM, Blue Swirl wrote: > >> > >> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori > >> wrote: > >> > Consider this a friendly reminder that we're only three weeks away from > >> > the > >> > soft feature freeze for 1.0. I've written a wiki page about my > >> > expectations > >> > for the soft feature freeze. It's inlined here for easier commenting. > >> > >> I think the freezes and the release should be delayed until the memory > >> API conversion is finished, deliberately shipping semi-broken code > >> just to satisfy schedules does not benefit anyone but the schedule > >> creator. It looks to me that converting all buses and devices might be > >> finished by the deadline but it may as well take a bit more until > >> everything works again. > >> > > > > There is a difference between "incomplete conversion" and "semi-broken > > code". Any breakage should be fixed promptly, but after some freeze date > > (not sure if this is the one proposed), additional conversions would be > > pushed to 1.1. > > Well, there's PPC VGA which is semi-broken by the incomplete conversion. Please point out a test case and I'll try to fix it. -- error compiling committee.c: too many arguments to function