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: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2
Date: Wed, 12 Jul 2017 17:37:57 -0300
User-agent: Mutt/1.8.0 (2017-02-23)

On Wed, Jul 12, 2017 at 05:29:01PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 06:23:51PM +0200, Paolo Bonzini wrote:
> > On 12/07/2017 18:12, Daniel P. Berrange wrote:
> > >> 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.  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 machine type and feature removal should be tied together.
> > 
> > Doing the opposite leaves around code that is more or less dead from an
> > upstream point of view, and looks like an ad hoc rule for Red Hat.  It
> > harms downstreams that do not participate in upstream development
> > (though perhaps this is an intended side effect?).
> 
> Yep, I'm amenable to that POV too. It is entirely valid to say that if
> downstream distros need to care about such ancient back-compat, then they
> will just have to do the extra work to use git history to undelete any bits
> they need that upstream has discarded.

If they do this, won't it be better to cooperate and let those
bits to be maintained in the upstream tree (as long as somebody
is willing to maintain them), instead of being kept in their own
downstream fork?

(That doesn't mean we shouldn't have a deprecation policy, but
that I would prefer to have the deprecation policy amended if
necessary than having a diverging fork maintained by a downstream
distro).

-- 
Eduardo



reply via email to

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