From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Alistair Francis <alistair.francis@xilinx.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Marcel Apfelbaum <marcel@redhat.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
Date: Sun, 21 Jan 2018 23:10:48 -0300 [thread overview]
Message-ID: <915da050-14bd-50ad-9a0d-5ad81fd34073@amsat.org> (raw)
In-Reply-To: <20171108202924.GV3111@localhost.localdomain>
Hi Thomas,
> This series introduces 5 different flavors of deprecation
> messages:
>
> * "Too old"
> * "Unmaintained"
> * "The ZCU102 machine has the same features supported"
> * "Use the \"pc\" machine instead"
> * "Obsoleted by the \"40p\" machine"
>
> Can we clearly document guidelines and examples for values of
> this field, to help ensure consistency?
>
> Examples of questions that could be answered in the field
> documentation:
>
> * Should the message start with an uppercase letter?
> * Should it really explain _why_ it was deprecated, or is a
> simple "please use xlnx-zcu102 instead" good enough?
> * Which of the following is preferred:
> * "obsoleted by the \"pc\" machine"
> * "obsoleted by \"pc\""
> * "use \"pc\" instead"
> * "too old, use \"pc\" instead"
> * "too old; use \"pc\" instead"
> * <something else?>
Do you have any preference regarding Eduardo's suggestions?
I see this pattern:
- obsoleted by newer
-> hint about replacement
- too old, unmaintained (maybe suggest use an older version?)
-> hint when removal is scheduled
These are also valid for Devices.
Now if we want a consistent guideline, I suggest we clearly document the
deprecated machines/devices in qemu-doc.texi and extract this
information at build time, like trace.h.
At least this will force developers to document their deprecations.
next prev parent reply other threads:[~2018-01-22 2:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
2017-11-08 10:23 ` Thomas Huth
2017-11-08 10:27 ` Daniel P. Berrange
2017-11-08 20:29 ` Eduardo Habkost
2018-01-22 2:10 ` Philippe Mathieu-Daudé [this message]
2018-01-22 6:21 ` Thomas Huth
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
2017-11-08 9:17 ` Daniel P. Berrange
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
2017-11-08 2:48 ` Alexey Kardashevskiy
2017-11-08 3:28 ` Philippe Mathieu-Daudé
2017-11-08 9:13 ` Daniel P. Berrange
2017-11-08 10:43 ` Thomas Huth
2017-11-08 9:16 ` Daniel P. Berrange
2017-11-08 10:15 ` Thomas Huth
2017-11-08 11:36 ` Thomas Huth
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
2017-11-08 3:29 ` Philippe Mathieu-Daudé
2017-11-08 9:09 ` Daniel P. Berrange
2017-11-08 9:44 ` Gerd Hoffmann
2017-11-08 10:05 ` Thomas Huth
2017-11-08 9:10 ` [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Daniel P. Berrange
2018-05-04 17:15 ` Thomas Huth
2018-05-08 15:47 ` Philippe Mathieu-Daudé
2018-05-11 13:55 ` [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines) Eduardo Habkost
2018-05-11 14:27 ` Cleber Rosa
2018-05-18 18:16 ` Alistair Francis
2018-05-22 16:17 ` Cleber Rosa
2018-05-22 16:34 ` Alistair Francis
2019-06-17 5:17 ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
2019-08-16 10:51 ` Philippe Mathieu-Daudé
2019-08-19 13:10 ` Cleber Rosa
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=915da050-14bd-50ad-9a0d-5ad81fd34073@amsat.org \
--to=f4bug@amsat.org \
--cc=alistair.francis@xilinx.com \
--cc=ehabkost@redhat.com \
--cc=marcel@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--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).