qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Richard Henderson <rth@twiddle.net>
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	[thread overview]
Message-ID: <20170712203757.GP6020@localhost.localdomain> (raw)
In-Reply-To: <20170712162901.GL5237@redhat.com>

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	other threads:[~2017-07-12 20:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12  8:22 [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2 Thomas Huth
2017-07-12 13:31 ` Gerd Hoffmann
2017-07-12 14:51 ` Eduardo Habkost
2017-07-12 15:17   ` Michael S. Tsirkin
2017-07-12 20:15     ` Eduardo Habkost
2017-07-12 20:31       ` Michael S. Tsirkin
2017-07-12 20:56         ` Eduardo Habkost
2017-07-12 22:27           ` Michael S. Tsirkin
2017-07-13  0:23             ` Laszlo Ersek
2017-07-13  0:45               ` Michael S. Tsirkin
2017-07-13  0:47               ` Michael S. Tsirkin
2017-07-13 15:17               ` Eduardo Habkost
2017-07-13 15:34                 ` Laszlo Ersek
2017-07-13 22:41                 ` Michael S. Tsirkin
2017-07-14 15:40                   ` Eduardo Habkost
2017-07-13 15:24       ` Eric Blake
2017-07-12 15:45   ` Markus Armbruster
2017-07-12 17:48     ` Eduardo Habkost
2017-07-12 15:04 ` Daniel P. Berrange
2017-07-12 16:00   ` Thomas Huth
2017-07-12 16:12     ` Daniel P. Berrange
2017-07-12 16:23       ` Thomas Huth
2017-07-12 16:32         ` Daniel P. Berrange
2017-07-12 16:23       ` Paolo Bonzini
2017-07-12 16:29         ` Daniel P. Berrange
2017-07-12 20:37           ` Eduardo Habkost [this message]
2017-07-13 23:14           ` Michael S. Tsirkin
2017-07-14 16:33             ` Eduardo Habkost
2017-07-12 20:26   ` Eduardo Habkost
2017-07-13  0:30 ` Laszlo Ersek
2017-07-13  0:47   ` Michael S. Tsirkin
2017-07-13  1:02     ` Laszlo Ersek
2017-07-13  1:00 ` Michael S. Tsirkin
2017-07-13 15:20   ` Eduardo Habkost
2017-07-13 23:04     ` Michael S. Tsirkin
2017-07-14  5:37       ` Thomas Huth
2017-07-14  9:50       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170712203757.GP6020@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=berrange@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).