From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC] docs: document support lifetime and deprecation policy
Date: Thu, 11 May 2017 10:32:40 +0100 [thread overview]
Message-ID: <20170511093240.GK8639@redhat.com> (raw)
In-Reply-To: <20170510163902.GG19962@stefanha-x1.localdomain>
On Wed, May 10, 2017 at 12:39:02PM -0400, Stefan Hajnoczi wrote:
> On Wed, May 10, 2017 at 12:15:35PM +0100, Daniel P. Berrange wrote:
> > The deprecation of features in QEMU is totally adhoc currently,
> > with no way for the user to get a list of what is deprecated
> > in each release. There is also no guidance on the duration of
> > support for features such as versioned machine types, which
> > have a finite useful life.
> >
> > This adds two new appendix entries to the main QEMU documentation.
> > The first appendix lists items which have finite lifecycles,
> > and sets out the policy that is used for deprecating & removing
> > features which have indefinite lifecycles. The second appendix
> > provides a list of all[1] currently deprecated features, along
> > with the release they were deprecated in.
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> >
> > [1] This is a lie. I've only listed one deprecated feature. Once
> > we agree on the general concept, we can fill out the doc
> > with the rest of the currently deprecated features.
> > ---
> > qemu-doc.texi | 47 +++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 47 insertions(+)
>
> Peter maydell is away in May. He usually participates in discussions on
> this topic. Unless there are urgent issues I suggest we wait until June
> to commit QEMU to new policies.
That's fine with me.
I just sent this because of the 'deprecate machine types' patch.
IMHO, we should decide on this general policy first, and only then
deprecate machine types in accordance with agreed policy, rather
than do an aribtrary deprecation of a bunch of machine types with
no clear idea of why we're picking them.
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 :|
prev parent reply other threads:[~2017-05-11 9:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 11:15 [Qemu-devel] [PATCH RFC] docs: document support lifetime and deprecation policy Daniel P. Berrange
2017-05-10 16:39 ` Stefan Hajnoczi
2017-05-11 9:32 ` Daniel P. Berrange [this message]
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=20170511093240.GK8639@redhat.com \
--to=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).