qemu-devel
[Top][All Lists]
Advanced

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

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


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2
Date: Wed, 12 Jul 2017 18:23:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 12.07.2017 18:12, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote:
>> On 12.07.2017 17:04, Daniel P. Berrange wrote:
[...]
>>> I think we must document & agree on our support policy for machine
>>> types, before we start marking them as deprecated. eg please consider
>>> the following document before accepting this deprecation patch:
>>>
>>>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
>>>
>>> Note in that proposal there, I say we do *not* go through trouble of
>>> explicitly marking machines as deprecated. We just document upfront
>>> the intended lifecycle and then delete them when it is done.
>>>
>>> Just use deprecation warnings for things where there is no predictable
>>> lifecycle upfront.
>>
>> I'm still not 100% sure whether that auto-deprecation of machine types
>> is such a good idea ... since we might need to maintain machines in
>> downstream a little bit longer than specified there, it might be better
>> to rather deprecate them manually from time to time.
> 
> Downstreams usually maintain custom machine types, so fact that the
> upstream machine types get deleted is not a problem in itself. The problem
> comes if followup internal code removal then prevents downstream from
> creating their custom machine type.

Right, that's what I had in mind.

> I don't think we need tie these
> issues together. We can remove old machine types, without immediately
> removing features that our harm creation of downstream machine types.

I think that won't work. Either the required code gets removed by
accident, or if not, we forget to remove it later, once downstream does
not require it anymore. I think it is better to remove machine types and
the related features code in the upstream code base in one shot. So
manually deprecating machine types and carefully removing them later
sounds like the better approach to me.

> FWIW, I think your proposals have been very useful in general. It has
> been way overdue to have this kind of discussion. I just want us to
> focus on defining a policy, rather than making adhoc decisions each
> time around, as the later is rather unpredictable for users of qemu.

Well, I think your doc updates are also a very good idea, but we could
simply state that we keep the old machine types around for *at least* x
releases or y years. That should give users the same safety as when
we're declaring that old machine types will definitely be removed after
x releases or y years.

 Thomas



reply via email to

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