qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [qemu-web PATCH] Add a blog post about deprecation of old interfaces and features
Date: Tue, 25 Jul 2017 12:27:42 +0100	[thread overview]
Message-ID: <20170725112741.GO26394@redhat.com> (raw)
In-Reply-To: <a7fa9a6b-d7f3-cfa7-4270-98507b817f93@redhat.com>

On Tue, Jul 25, 2017 at 01:23:24PM +0200, Thomas Huth wrote:
> On 25.07.2017 13:15, Daniel P. Berrange wrote:
> > On Tue, Jul 25, 2017 at 01:10:38PM +0200, Paolo Bonzini wrote:
> >> On 25/07/2017 13:07, Thomas Huth wrote:
> >>> The list of deprecated interfaces/features in the wiki should be pretty
> >>> complete now, so it is now time to draw some more public attention to our
> >>> plans of removing certain interfaces/features in future releases.
> >>>
> >>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>> ---
> >>>  _posts/2017-07-25-deprecation.md | 26 ++++++++++++++++++++++++++
> >>>  1 file changed, 26 insertions(+)
> >>>  create mode 100644 _posts/2017-07-25-deprecation.md
> >>>
> >>> diff --git a/_posts/2017-07-25-deprecation.md b/_posts/2017-07-25-deprecation.md
> >>> new file mode 100644
> >>> index 0000000..b5eaf0b
> >>> --- /dev/null
> >>> +++ b/_posts/2017-07-25-deprecation.md
> >>> @@ -0,0 +1,26 @@
> >>> +---
> >>> +layout: post
> >>> +title:  "Deprecation of old parameters and features"
> >>> +date:   2017-07-25 9:00:00 +0200
> >>> +author: Thomas Huth
> >>> +categories: [features, 'web site']
> >>
> >> Maybe s/web site/wiki/?
> >>
> >>> +---
> >>> +QEMU has a lot of interfaces (like command line options or HMP commands) and
> >>> +old features (like certain devices) which are considered as deprecated
> >>> +since other more generic or better interfaces/features have been established
> >>> +instead. While the QEMU developers are generally trying to keep each QEMU
> >>> +release compatible with the previous ones, the old legacy sometimes gets into
> >>> +the way when developing new code and/or causes quite some burden of maintaining
> >>> +it.
> >>> +
> >>> +Thus we are currently considering to get rid of some of the old interfaces
> >>> +and features in a future release and have started to collect a list of such
> >>> +old items in our Wiki on a
> >>> +[page about removing legacy parts](http://wiki.qemu.org/Features/LegacyRemoval).
> >>> +If you are running QEMU directly, please have a look at this page to see
> >>> +whether you are still using one of these old interfaces or features, so you
> >>> +can adapt your setup to use the new interfaces or features instead. Or if
> >>> +you rather think that one of the legacy interfaces/features should *not* be
> >>> +removed from QEMU at all, please speak up on the
> >>> +[qemu-devel mailing list](http://wiki.qemu.org/Contribute/MailingLists)
> >>> +to explain why the interface or feature is still required.
> >>
> >> This text looks good.
> >>
> >> However, we should first finalize Daniel's patches and update the wiki
> >> to match the newly-instated policy.  The blog post might also include
> >> the text that is added to the manual.
> > 
> > IMHO we shouldn't really point people to the wiki at all. The qemu-doc
> > content is what any 3rd parties should rely, since that has been formally
> > reviewed & approved by maintainers.
> > 
> > The remaining content on the wiki page that differs from qemu-doc, is a
> > braindump of stuff that could potentially be removed, but is not at all
> > certain that any will be deprecated. IOW the wiki page is fine for QEMU
> > maintainers to use, but 3rd parties should only use the published docs.
> 
> Ok, your points about the wiki are certainly true ... but so far we
> still haven't decided on a final wording for qemu-doc yet ... or do we
> have an agreement on the machine type deprecation already? Maybe it's
> really best if you omit the part about machine type deprecation there
> for now, and discuss that again in the 2.11 time frame, so that we at
> least get the other parts still into the qemu-doc for 2.10 ?

Yes, I have just dropped the machine type content and sent a v6.

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-25 11:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25 11:07 [Qemu-devel] [qemu-web PATCH] Add a blog post about deprecation of old interfaces and features Thomas Huth
2017-07-25 11:10 ` Paolo Bonzini
2017-07-25 11:15   ` Daniel P. Berrange
2017-07-25 11:23     ` Thomas Huth
2017-07-25 11:27       ` 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=20170725112741.GO26394@redhat.com \
    --to=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).