All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Eduardo Habkost <ehabkost@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:32:58 +0100	[thread overview]
Message-ID: <20170712163258.GM5237@redhat.com> (raw)
In-Reply-To: <97146c9d-c6c9-161a-f9a0-1a065c183a35@redhat.com>

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	other threads:[~2017-07-12 16:33 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 [this message]
2017-07-12 16:23       ` Paolo Bonzini
2017-07-12 16:29         ` Daniel P. Berrange
2017-07-12 20:37           ` Eduardo Habkost
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=20170712163258.GM5237@redhat.com \
    --to=berrange@redhat.com \
    --cc=ehabkost@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.