From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8pjI-00023q-Rb for qemu-devel@nongnu.org; Thu, 11 May 2017 11:10:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8pjF-0006SF-UV for qemu-devel@nongnu.org; Thu, 11 May 2017 11:10:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33024) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d8pjF-0006Qq-M2 for qemu-devel@nongnu.org; Thu, 11 May 2017 11:10:09 -0400 From: Markus Armbruster References: <1494398933-8366-1-git-send-email-thuth@redhat.com> <20170510090841.GF31558@redhat.com> <20170510103153.GI31558@redhat.com> <157a6609-d75a-5d40-e5b9-c70802e40950@redhat.com> <20170511093022.GJ8639@redhat.com> Date: Thu, 11 May 2017 17:10:02 +0200 In-Reply-To: <20170511093022.GJ8639@redhat.com> (Daniel P. Berrange's message of "Thu, 11 May 2017 10:30:22 +0100") Message-ID: <87poffsa45.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , Thomas Huth , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, kraxel@redhat.com, Richard Henderson "Daniel P. Berrange" writes: > On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote: >> >> >> On 10/05/2017 16:47, Thomas Huth wrote: >> >> So while we can delete pc-0.12, we can't delete associated features needed >> >> by pc-0.12, without complicating RHEL's ability to create its back-compat >> >> machine types. Downstream would have to un-delete the features. >> > >> > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I >> > think removing pc-0.12, but not removing rombar=0 will cause confusion >> > in the upstream code base sooner or later, >> >> I agree. >> >> > so I guess we should rather >> > keep the pc-0.12 machine until we can get rid of it together with the >> > rombar code. We should still mark it as deprecated, of course. >> > >> >> I think tieing removal to major versions is a mistake, unless we're >> >> going to set a fixed timeframe for delivery of major versions. ie if >> >> we gaurantee that we'll ship a new major version every 18 months, that >> >> gives people a predictable lifetime. If we carry on inventing reasons >> >> for major versions at arbitrary points in time, it makes it difficult >> >> to have any reasonable forward planning. It is more users friendly if >> >> we can set a clear fixed timeframe for machine type lifecycle / eol >> > >> > IMHO we should have a new major release after we've reached a .9 minor >> > release, but so far it seems like I'm the only one with that wish... >> >> I actually like that, but then you've pretty much guaranteed that you >> _cannot_ remove anything deprecated until 4.0. You and Daniel aren't >> disagreeing as heavily as it seems, I think. > > I don't think we should tie removal of features to version numbers. IMHO > we should just increment the first major digit on a fixed time scale, > either once a year, or whenever we get past .9. > > For removal of features, IMHO, the only important thing is to give users > deprecation clear warning for 2-3 releases, and ensure feature detection > works well. As long as that is done, there shouldn't be any need to batch > them up for "major" releases. From libvirt POV, batching up removal to > major releases is not beneficial. Batching to major releases gives a very > inconsistent timeframe for removal too - somethign fdeprecated in .1 > release may live on for years, until the next $major.0, while something > deprecated in a .9 release can be killed in 4 months. I much prefer to > see a consistent deprecated for 2 releases / 8 months, then deleted > regardless of feature. I concur.