From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YT869-0008DF-WA for qemu-devel@nongnu.org; Wed, 04 Mar 2015 07:08:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YT863-0005iJ-C2 for qemu-devel@nongnu.org; Wed, 04 Mar 2015 07:08:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YT863-0005i5-3r for qemu-devel@nongnu.org; Wed, 04 Mar 2015 07:08:15 -0500 Message-ID: <1425470885.8389.43.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 04 Mar 2015 13:08:05 +0100 In-Reply-To: <54F5CE1D.7050802@redhat.com> References: <54F45893.5080802@redhat.com> <54F4618D.1050205@redhat.com> <54F5B345.4010706@gmail.com> <54F5BDD5.5070706@redhat.com> <54F5CE1D.7050802@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Delaying -rc0? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Paolo Bonzini , kevin@koconnor.net, qemu-devel , Peter Maydell Hi, > Well, the support was ready in time, see: > [SeaBIOS] [PATCH V3 0/2] fw/pci: better support for multiple host bridges > http://permalink.gmane.org/gmane.comp.bios.coreboot.seabios/8681 > but the SeaBIOS maintainers preferred to see first the QEMU submission > getting accepted. Yep, that is the usual protocol to avoid ending up with stale code in seabios because the qemu patches never make it upstream. I havn't seen major objections on the RfC series, so I think it is ok to go ahead committing the seabios patches when the dependencies are merged, we have a non-rfc patch submission, and there is agreement this is going to be merged for 2.3. That way we can parallelize the qemu and seabios side of things a bit, to get both ready in time for -rc0. > In the mean time this series depends on Igor's ACPI dynamic series that took > a lot of time to review and even Michael's PULL request with it is not yet in master. That's the real blocking thing here ... cheers, Gerd