qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: "Markus Armbruster" <armbru@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-trivial@nongnu.org, Thomas Huth <thuth@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] qemu-deprecated: Remove text about Python 2
Date: Wed, 15 Jan 2020 12:16:32 -0500	[thread overview]
Message-ID: <efe0d310-1c48-4f1b-2ffe-46eea85af871@redhat.com> (raw)
In-Reply-To: <874kww7lk3.fsf@dusky.pond.sub.org>



On 1/15/20 11:04 AM, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
>> On Tue, Jan 14, 2020 at 11:08:16AM +0100, Thomas Huth wrote:
>>> On 13/01/2020 23.36, John Snow wrote:
>>>> Right now, we don't
>>>> really have these docs hosted in a searchable way online in a
>>>> per-version format. Once the notice is gone, it's gone from the mirror.
>>>>
>>>> I removed some bitmap functionality not too long ago and I created a
>>>> "Recently Removed" section as a bit of a troubleshooting guide should it
>>>> be needed.
>>>>
>>>> - Do we want this section?
>>>> - Should I remove it?
>>>> - Can we add historical docs to the website to see previous deprecated
>>>> docs in a searchable manner?
>>>
>>> I also once started a page in the Wiki here:
>>>
>>>  https://wiki.qemu.org/Features/RemovedFeatures
>>>
>>> ... but apparently, it did not get enough attention yet, otherwise you
>>> would have noticed it before introducing the new chapter into the
>>> qemu-doc ...
>>>
>>> We definitely need one spot where we can document removed features. I
>>> don't mind which way we do it, either the qemu-doc or the wiki, but we
>>> should unify on one of the two. I guess the qemu-doc is the better place
>>> since we are tracking the deprecated features there already and one more
>>> or less just has to move the text to the other chapter when things get
>>> finally removed?
>>
>> Yeah, I've said in the past that we should not be deleting deprecations
>> from the docs entirely.
>>
>> If you look at GTK docs for example, you'll see they keep a record of
>> all incompatible or noteworth changes between release:
>>
>>   https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to-y.html
>>
>> IMHO, we should follow this and have an appendix of removed features,
>> with sub-sections per QEMU release listing each removed feature. Thus
>> deprecation docs just get moved to this appendix at the right time.
> 
> This is exactly the "Recently Removed" appendix John added in commit
> 3264ffced3d.
> 
> Now we need a sucker^Wvolunteer to restore all the stuff we dropped from
> appendix "Deprecated features" to this appendix.  John, you were
> incautious enough to signal you care; what about you?
> 

Can add to the pile, but admittedly I am a little backlogged trying to
recover from the holidays. I can't promise any time to it right this minute.

I can try next week, if I don't forget.



  reply	other threads:[~2020-01-15 17:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09  9:51 [PATCH] qemu-deprecated: Remove text about Python 2 Thomas Huth
2020-01-09 12:49 ` Aleksandar Markovic
2020-01-29 22:13   ` Philippe Mathieu-Daudé
2020-01-29 23:18     ` Aleksandar Markovic
2020-01-29 23:26       ` Philippe Mathieu-Daudé
2020-01-13 22:36 ` John Snow
2020-01-14 10:08   ` Thomas Huth
2020-01-14 10:20     ` Daniel P. Berrangé
2020-01-14 15:53       ` John Snow
2020-01-15 16:04       ` Markus Armbruster
2020-01-15 17:16         ` John Snow [this message]
2020-01-30 22:09           ` Philippe Mathieu-Daudé
2020-03-16 18:16             ` John Snow
2020-01-30 22:13 ` Philippe Mathieu-Daudé

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=efe0d310-1c48-4f1b-2ffe-46eea85af871@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@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).