From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhanF-0001Dh-O9 for qemu-devel@nongnu.org; Wed, 29 May 2013 03:27:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhanB-0002cr-R5 for qemu-devel@nongnu.org; Wed, 29 May 2013 03:27:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhanB-0002cd-JG for qemu-devel@nongnu.org; Wed, 29 May 2013 03:27:29 -0400 Message-ID: <51A5ADD4.5090507@redhat.com> Date: Wed, 29 May 2013 09:27:16 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <20130527125946.GA15820@morn.localdomain> <51A35B92.7020806@msgid.tls.msk.ru> <20130529000853.GA16591@morn.localdomain> In-Reply-To: <20130529000853.GA16591@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [coreboot] [SeaBIOS] SeaBIOS v1.7.2.2 stable release List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, Michael Tokarev , qemu-devel@nongnu.org, coreboot@coreboot.org On 05/29/13 02:08, Kevin O'Connor wrote: > On Mon, May 27, 2013 at 05:11:46PM +0400, Michael Tokarev wrote: >> 27.05.2013 16:59, Kevin O'Connor wrote: >>> A new stable release of SeaBIOS (version 1.7.2.2) has been tagged. >>> This release contains bug fixes. >>> >>> The release is available via git: >>> git clone git://git.seabios.org/seabios -b 1.7.2-stable >> >> Just.. curious -- why there are no tarballs for the dotdot-point >> releases like this one? Not that it's hugely important to have >> the tarballs but... :) > > I thought the stable releases would have a smaller audience, so didn't > think it was needed. qemu upstream project doesn't need tarballs as it simply uses a git submodule. distros usually compile seabios from source instead of using the prebuild binary included in the qemu tarball (for gpl compliance and other reasons). So having tarballs even for minor releases is useful. While talking about releases: There are quite some changes accumulated in master, time to cut a new release I think. Given that sorting the acpi table issue seems to take more time than expected, how about freeze + call for patches _now_, release 1.7.3 some-when in June, then plan to merge the apci changes (however it works out) for 1.7.4? cheers, Gerd