From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7T9G-0000I4-63 for qemu-devel@nongnu.org; Wed, 16 Jul 2014 13:37:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X7T99-00064C-62 for qemu-devel@nongnu.org; Wed, 16 Jul 2014 13:37:46 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:55408 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7T98-00062z-Re for qemu-devel@nongnu.org; Wed, 16 Jul 2014 13:37:39 -0400 Message-ID: <53C6B85D.4060400@kamp.de> Date: Wed, 16 Jul 2014 19:37:33 +0200 From: Peter Lieven MIME-Version: 1.0 References: <20140716002632.23073.40357@loki> <53C6A816.9090306@weilnetz.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Stefan Weil Cc: QEMU Developers Am 16.07.2014 18:46, schrieb Peter Maydell: > On 16 July 2014 17:28, Stefan Weil wrote: >> a recent commit (e49ab19fcaa617ad6cdfe1ac401327326b6a2552) increased the >> requirements for libiscsi from 1.4.0 to 1.9.0. From a user's point of >> view, this change results in a regression for Debian and similar Linux >> distributions: QEMU no longer includes iscsi features. >> >> In this special case, the current Debian stable includes QEMU packages >> with libiscsi 1.4, but new builds won't include it because that version >> is now too old. Debian testing includes a brand new libiscsi, but it >> does not include libiscsi.pc, so pkg-config won't know that it is >> available and configure will disable libiscsi. I have a patch which >> fixes this, so QEMU for Debian testing could include libiscsi again. >> >> Is a feature regression like this one acceptable? Do we need additional >> testing (maybe run the build bots with --enable-xxx, so builds fail when >> xxx no longer works)? > In general, we should try to avoid feature regressions, but it's > going to be a case-by-case thing. In this particular instance, > upstream libiscsi don't recommend pre-1.9 for production use > (as the commit message documents), and I don't think we would > be doing our users any favours by allowing them to build something > that's likely to be broken. We should of course flag up this sort of > "minimum version of our dependencies has been bumped" info in > the release notes. I will update the Wiki. Peter > > I think that "does QEMU still build with all the features we need on > our distro?" has to be testing done by the people who package and > maintain QEMU for each distro -- they're the only people who know > which configurations options they enable and which baseline versions > of their distro they still care about packaging mainline QEMU for. > > thanks > -- PMM