qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15
Date: Fri, 12 May 2017 08:55:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 11.05.2017 17:10, Markus Armbruster wrote:
> "Daniel P. Berrange" <address@hidden> 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.

Once a year sounds too often for my personal taste, I really prefer the
.9 way, but that's details...

>> 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.

Fine for me, too. My only additional point is that we *should* have
major releases from time to time (ending up with something like QEMU
2.42 is just ugly), and that we *could* use them for additional
spring-cleaning (not for the libvirt POV, but for the users POV). For
example, we've got some parameters where we warn since QEMU 1.3 that it
is deprecated and might go away soon. We now could use major releases to
remind ourselves from time to time to look through the code for such
deprecated interfaces and remove them with the next major version. (But
removal would of course also be allowed at any other minor version
release if the feature has been deprecated for at least two minor
releases already).

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]