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: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2
Date: Wed, 12 Jul 2017 17:32:58 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

On Wed, Jul 12, 2017 at 06:23:39PM +0200, Thomas Huth wrote:
> 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.

I really don't like saying "at least", as it means every time we want
to actually delete something that we have previously deprecated, we
have to have a debate about whether it can actually go and make an
arbitrary decision about whether to accept someone's objection to
the deletion. Giving a clear finite timeframe sets expectations
right from the start, and avoids us playing favourites to particular
people who want stuff kept around

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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