qemu-deprecated: Remove text about Python 2
diff mbox series

Message ID 20200109095116.18201-1-thuth@redhat.com
State New
Headers show
Series
  • qemu-deprecated: Remove text about Python 2
Related show

Commit Message

Thomas Huth Jan. 9, 2020, 9:51 a.m. UTC
Python 2 support has been removed, so we should now also remove
the announcement text for the deprecation.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 qemu-deprecated.texi | 8 --------
 1 file changed, 8 deletions(-)

Comments

Aleksandar Markovic Jan. 9, 2020, 12:49 p.m. UTC | #1
On Thursday, January 9, 2020, Thomas Huth <thuth@redhat.com> wrote:

> Python 2 support has been removed, so we should now also remove
> the announcement text for the deprecation.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  qemu-deprecated.texi | 8 --------
>  1 file changed, 8 deletions(-)
>
>
Reviewed by: Aleksandar Markovic <amarkovic@wavecomp.com>


> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 7033e531de..8b23e98474 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to
> skip image creation.
>  Silently ignored options can be confusing, so this combination of
>  options will be made an error in future versions.
>
> -@section Build system
> -
> -@subsection Python 2 support (since 4.1.0)
> -
> -In the future, QEMU will require Python 3 to be available at
> -build time.  Support for Python 2 in scripts shipped with QEMU
> -is deprecated.
> -
>  @section Backwards compatibility
>
>  @subsection Runnability guarantee of CPU models (since 4.1.0)
> --
> 2.18.1
>
>
>
John Snow Jan. 13, 2020, 10:36 p.m. UTC | #2
On 1/9/20 4:51 AM, Thomas Huth wrote:
> Python 2 support has been removed, so we should now also remove
> the announcement text for the deprecation.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: John Snow <jsnow@redhat.com>

> ---
>  qemu-deprecated.texi | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 7033e531de..8b23e98474 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to skip image creation.
>  Silently ignored options can be confusing, so this combination of
>  options will be made an error in future versions.
>  
> -@section Build system
> -
> -@subsection Python 2 support (since 4.1.0)
> -
> -In the future, QEMU will require Python 3 to be available at
> -build time.  Support for Python 2 in scripts shipped with QEMU
> -is deprecated.
> -
>  @section Backwards compatibility
>  
>  @subsection Runnability guarantee of CPU models (since 4.1.0)
> 

Genuine question, I'm sorry:

Is it worth documenting things we recently removed? 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?

--js
Thomas Huth Jan. 14, 2020, 10:08 a.m. UTC | #3
On 13/01/2020 23.36, John Snow wrote:
> 
> 
> On 1/9/20 4:51 AM, Thomas Huth wrote:
>> Python 2 support has been removed, so we should now also remove
>> the announcement text for the deprecation.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
> Reviewed-by: John Snow <jsnow@redhat.com>
> 
>> ---
>>  qemu-deprecated.texi | 8 --------
>>  1 file changed, 8 deletions(-)
>>
>> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>> index 7033e531de..8b23e98474 100644
>> --- a/qemu-deprecated.texi
>> +++ b/qemu-deprecated.texi
>> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to skip image creation.
>>  Silently ignored options can be confusing, so this combination of
>>  options will be made an error in future versions.
>>  
>> -@section Build system
>> -
>> -@subsection Python 2 support (since 4.1.0)
>> -
>> -In the future, QEMU will require Python 3 to be available at
>> -build time.  Support for Python 2 in scripts shipped with QEMU
>> -is deprecated.
>> -
>>  @section Backwards compatibility
>>  
>>  @subsection Runnability guarantee of CPU models (since 4.1.0)
>>
> 
> Genuine question, I'm sorry:
> 
> Is it worth documenting things we recently removed?

Basically yes. In case of Python 2, it's not a QEMU feature that we
remove here, but a build requirement, and we tell the users that we need
at least Python 3.5 when they run "configure", so I'm not sure whether
that needs to be explicitely mentioned again the docs beside our ChangeLog?

> 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?

 Thomas
Daniel P. Berrangé Jan. 14, 2020, 10:20 a.m. UTC | #4
On Tue, Jan 14, 2020 at 11:08:16AM +0100, Thomas Huth wrote:
> On 13/01/2020 23.36, John Snow wrote:
> > 
> > 
> > On 1/9/20 4:51 AM, Thomas Huth wrote:
> >> Python 2 support has been removed, so we should now also remove
> >> the announcement text for the deprecation.
> >>
> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
> > 
> > Reviewed-by: John Snow <jsnow@redhat.com>
> > 
> >> ---
> >>  qemu-deprecated.texi | 8 --------
> >>  1 file changed, 8 deletions(-)
> >>
> >> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> >> index 7033e531de..8b23e98474 100644
> >> --- a/qemu-deprecated.texi
> >> +++ b/qemu-deprecated.texi
> >> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to skip image creation.
> >>  Silently ignored options can be confusing, so this combination of
> >>  options will be made an error in future versions.
> >>  
> >> -@section Build system
> >> -
> >> -@subsection Python 2 support (since 4.1.0)
> >> -
> >> -In the future, QEMU will require Python 3 to be available at
> >> -build time.  Support for Python 2 in scripts shipped with QEMU
> >> -is deprecated.
> >> -
> >>  @section Backwards compatibility
> >>  
> >>  @subsection Runnability guarantee of CPU models (since 4.1.0)
> >>
> > 
> > Genuine question, I'm sorry:
> > 
> > Is it worth documenting things we recently removed?
> 
> Basically yes. In case of Python 2, it's not a QEMU feature that we
> remove here, but a build requirement, and we tell the users that we need
> at least Python 3.5 when they run "configure", so I'm not sure whether
> that needs to be explicitely mentioned again the docs beside our ChangeLog?

In general changed build pre-requisites such as new minimum software
versions are documented in the release notes:

   https://wiki.qemu.org/ChangeLog/5.0#Build_Information

We normally would not list build pre-requisites in the deprecation notes
at all, since they don't follow the deprecation process normally. We
just update minimum versions immediately that our supported OS build
platforms change due to an OS going end of life. So for example we
have in the past bumped gnutls, glib, nettle, gcc, etc min versions
with no warning.  So the fact that Python 2 was mentioned in the
deprecations at all was slightly unusual. This is mostly just to be
nice to users since the OS platforms here aren't going EOL and still
ship Python 2, we simply don't wish to support it any more, since
the distros also all have Py 3.


> 
> > 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.

Regards,
Daniel
John Snow Jan. 14, 2020, 3:53 p.m. UTC | #5
On 1/14/20 5:20 AM, Daniel P. Berrangé wrote:
> On Tue, Jan 14, 2020 at 11:08:16AM +0100, Thomas Huth wrote:
>> On 13/01/2020 23.36, John Snow wrote:
>>>
>>>
>>> On 1/9/20 4:51 AM, Thomas Huth wrote:
>>>> Python 2 support has been removed, so we should now also remove
>>>> the announcement text for the deprecation.
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>
>>> Reviewed-by: John Snow <jsnow@redhat.com>
>>>
>>>> ---
>>>>  qemu-deprecated.texi | 8 --------
>>>>  1 file changed, 8 deletions(-)
>>>>
>>>> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>>>> index 7033e531de..8b23e98474 100644
>>>> --- a/qemu-deprecated.texi
>>>> +++ b/qemu-deprecated.texi
>>>> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to skip image creation.
>>>>  Silently ignored options can be confusing, so this combination of
>>>>  options will be made an error in future versions.
>>>>  
>>>> -@section Build system
>>>> -
>>>> -@subsection Python 2 support (since 4.1.0)
>>>> -
>>>> -In the future, QEMU will require Python 3 to be available at
>>>> -build time.  Support for Python 2 in scripts shipped with QEMU
>>>> -is deprecated.
>>>> -
>>>>  @section Backwards compatibility
>>>>  
>>>>  @subsection Runnability guarantee of CPU models (since 4.1.0)
>>>>
>>>
>>> Genuine question, I'm sorry:
>>>
>>> Is it worth documenting things we recently removed?
>>
>> Basically yes. In case of Python 2, it's not a QEMU feature that we
>> remove here, but a build requirement, and we tell the users that we need
>> at least Python 3.5 when they run "configure", so I'm not sure whether
>> that needs to be explicitely mentioned again the docs beside our ChangeLog?
> 
> In general changed build pre-requisites such as new minimum software
> versions are documented in the release notes:
> 
>    https://wiki.qemu.org/ChangeLog/5.0#Build_Information
> 
> We normally would not list build pre-requisites in the deprecation notes
> at all, since they don't follow the deprecation process normally. We
> just update minimum versions immediately that our supported OS build
> platforms change due to an OS going end of life. So for example we
> have in the past bumped gnutls, glib, nettle, gcc, etc min versions
> with no warning.  So the fact that Python 2 was mentioned in the
> deprecations at all was slightly unusual. This is mostly just to be
> nice to users since the OS platforms here aren't going EOL and still
> ship Python 2, we simply don't wish to support it any more, since
> the distros also all have Py 3.
> 
> 
>>
>>> 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.
> 
> Regards,
> Daniel
> 

Everything said makes sense to me. My review here stands, thanks! (Sorry
for the derail.)

--js
Markus Armbruster Jan. 15, 2020, 4:04 p.m. UTC | #6
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?
John Snow Jan. 15, 2020, 5:16 p.m. UTC | #7
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.
Philippe Mathieu-Daudé Jan. 29, 2020, 10:13 p.m. UTC | #8
Hi Aleksandar,

On 1/9/20 1:49 PM, Aleksandar Markovic wrote:
> 
> 
> On Thursday, January 9, 2020, Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com>> wrote:
> 
>     Python 2 support has been removed, so we should now also remove
>     the announcement text for the deprecation.
> 
>     Signed-off-by: Thomas Huth <thuth@redhat.com <mailto:thuth@redhat.com>>
>     ---
>       qemu-deprecated.texi | 8 --------
>       1 file changed, 8 deletions(-)
> 
> 
> Reviewed by: Aleksandar Markovic <amarkovic@wavecomp.com 
> <mailto:amarkovic@wavecomp.com>>

I use pwclient to collect patchwork patches, this one is:
https://patchwork.kernel.org/patch/11325373/
Your comment is listed, but your tag is ignored... I am not sure why.

John used:
Content-Transfer-Encoding: 7bit

You:
Content-Transfer-Encoding: quoted-printable

This might be why? I have no clue.

> 
>     diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>     index 7033e531de..8b23e98474 100644
>     --- a/qemu-deprecated.texi
>     +++ b/qemu-deprecated.texi
>     @@ -341,14 +341,6 @@ they have no effect when used with @option{-n}
>     to skip image creation.
>       Silently ignored options can be confusing, so this combination of
>       options will be made an error in future versions.
> 
>     -@section Build system
>     -
>     -@subsection Python 2 support (since 4.1.0)
>     -
>     -In the future, QEMU will require Python 3 to be available at
>     -build time.  Support for Python 2 in scripts shipped with QEMU
>     -is deprecated.
>     -
>       @section Backwards compatibility
> 
>       @subsection Runnability guarantee of CPU models (since 4.1.0)
>     -- 
>     2.18.1
> 
>
Aleksandar Markovic Jan. 29, 2020, 11:18 p.m. UTC | #9
23:14 Sre, 29.01.2020. Philippe Mathieu-Daudé <philmd@redhat.com> је
написао/ла:
>
> Hi Aleksandar,
>
> On 1/9/20 1:49 PM, Aleksandar Markovic wrote:
> >
> >
> > On Thursday, January 9, 2020, Thomas Huth <thuth@redhat.com
> > <mailto:thuth@redhat.com>> wrote:
> >
> >     Python 2 support has been removed, so we should now also remove
> >     the announcement text for the deprecation.
> >
> >     Signed-off-by: Thomas Huth <thuth@redhat.com <mailto:
thuth@redhat.com>>
> >     ---
> >       qemu-deprecated.texi | 8 --------
> >       1 file changed, 8 deletions(-)
> >
> >
> > Reviewed by: Aleksandar Markovic <amarkovic@wavecomp.com
> > <mailto:amarkovic@wavecomp.com>>
>
> I use pwclient to collect patchwork patches, this one is:
> https://patchwork.kernel.org/patch/11325373/
> Your comment is listed, but your tag is ignored... I am not sure why.
>
> John used:
> Content-Transfer-Encoding: 7bit
>
> You:
> Content-Transfer-Encoding: quoted-printable
>
> This might be why? I have no clue.
>

It could be. I use a variety of mail clients. Not all provide the same
level of control of sent mails format. Almost sure they have different
settings. I may do some experimentation on a suitable patch series. Thanks
for noticing it.

OR: I wrote "Reviewed by:" without hyphen.

Reviewed-by: Aleksandar Markovic  <amarkovic@wavecomp.com>

Is now patchwork picking it up?

> >
> >     diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> >     index 7033e531de..8b23e98474 100644
> >     --- a/qemu-deprecated.texi
> >     +++ b/qemu-deprecated.texi
> >     @@ -341,14 +341,6 @@ they have no effect when used with @option{-n}
> >     to skip image creation.
> >       Silently ignored options can be confusing, so this combination of
> >       options will be made an error in future versions.
> >
> >     -@section Build system
> >     -
> >     -@subsection Python 2 support (since 4.1.0)
> >     -
> >     -In the future, QEMU will require Python 3 to be available at
> >     -build time.  Support for Python 2 in scripts shipped with QEMU
> >     -is deprecated.
> >     -
> >       @section Backwards compatibility
> >
> >       @subsection Runnability guarantee of CPU models (since 4.1.0)
> >     --
> >     2.18.1
> >
> >
>
Philippe Mathieu-Daudé Jan. 29, 2020, 11:26 p.m. UTC | #10
On 1/30/20 12:18 AM, Aleksandar Markovic wrote:
> 23:14 Sre, 29.01.2020. Philippe Mathieu-Daudé <philmd@redhat.com 
> <mailto:philmd@redhat.com>> је написао/ла:
>  >
>  > Hi Aleksandar,
>  >
>  > On 1/9/20 1:49 PM, Aleksandar Markovic wrote:
>  > >
>  > >
>  > > On Thursday, January 9, 2020, Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com>
>  > > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote:
>  > >
>  > >     Python 2 support has been removed, so we should now also remove
>  > >     the announcement text for the deprecation.
>  > >
>  > >     Signed-off-by: Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com> <mailto:thuth@redhat.com 
> <mailto:thuth@redhat.com>>>
>  > >     ---
>  > >       qemu-deprecated.texi | 8 --------
>  > >       1 file changed, 8 deletions(-)
>  > >
>  > >
>  > > Reviewed by: Aleksandar Markovic <amarkovic@wavecomp.com 
> <mailto:amarkovic@wavecomp.com>
>  > > <mailto:amarkovic@wavecomp.com <mailto:amarkovic@wavecomp.com>>>
>  >
>  > I use pwclient to collect patchwork patches, this one is:
>  > https://patchwork.kernel.org/patch/11325373/
>  > Your comment is listed, but your tag is ignored... I am not sure why.
>  >
>  > John used:
>  > Content-Transfer-Encoding: 7bit
>  >
>  > You:
>  > Content-Transfer-Encoding: quoted-printable
>  >
>  > This might be why? I have no clue.
>  >
> 
> It could be. I use a variety of mail clients. Not all provide the same 
> level of control of sent mails format. Almost sure they have different 
> settings. I may do some experimentation on a suitable patch series. 
> Thanks for noticing it.
> 
> OR: I wrote "Reviewed by:" without hyphen.

Oh you are right, I didn't notice.

> 
> Reviewed-by: Aleksandar Markovic  <amarkovic@wavecomp.com 
> <mailto:amarkovic@wavecomp.com>>
> 
> Is now patchwork picking it up?

Yes (1 extra space after your name).

Thanks.

> 
>  > >
>  > >     diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>  > >     index 7033e531de..8b23e98474 100644
>  > >     --- a/qemu-deprecated.texi
>  > >     +++ b/qemu-deprecated.texi
>  > >     @@ -341,14 +341,6 @@ they have no effect when used with @option{-n}
>  > >     to skip image creation.
>  > >       Silently ignored options can be confusing, so this combination of
>  > >       options will be made an error in future versions.
>  > >
>  > >     -@section Build system
>  > >     -
>  > >     -@subsection Python 2 support (since 4.1.0)
>  > >     -
>  > >     -In the future, QEMU will require Python 3 to be available at
>  > >     -build time.  Support for Python 2 in scripts shipped with QEMU
>  > >     -is deprecated.
>  > >     -
>  > >       @section Backwards compatibility
>  > >
>  > >       @subsection Runnability guarantee of CPU models (since 4.1.0)
>  > >     --
>  > >     2.18.1
>  > >
>  > >
>  >
>
Philippe Mathieu-Daudé Jan. 30, 2020, 10:09 p.m. UTC | #11
On 1/15/20 6:16 PM, John Snow wrote:
> 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.

In case you forgot :P
Philippe Mathieu-Daudé Jan. 30, 2020, 10:13 p.m. UTC | #12
On 1/9/20 10:51 AM, Thomas Huth wrote:
> Python 2 support has been removed, so we should now also remove
> the announcement text for the deprecation.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>   qemu-deprecated.texi | 8 --------
>   1 file changed, 8 deletions(-)
> 
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 7033e531de..8b23e98474 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -341,14 +341,6 @@ they have no effect when used with @option{-n} to skip image creation.
>   Silently ignored options can be confusing, so this combination of
>   options will be made an error in future versions.
>   
> -@section Build system
> -
> -@subsection Python 2 support (since 4.1.0)
> -
> -In the future, QEMU will require Python 3 to be available at
> -build time.  Support for Python 2 in scripts shipped with QEMU
> -is deprecated.
> -
>   @section Backwards compatibility
>   
>   @subsection Runnability guarantee of CPU models (since 4.1.0)
> 

Thanks, applied to my python-next tree:
https://gitlab.com/philmd/qemu/commits/python-next
John Snow March 16, 2020, 6:16 p.m. UTC | #13
On 1/30/20 5:09 PM, Philippe Mathieu-Daudé wrote:
> On 1/15/20 6:16 PM, John Snow wrote:
>> 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.
> 
> In case you forgot :P
> 

Working on it.

Here's the list:

3.1.0:

b24ec3c46281286a6a5624d0ceb5fa6f30bd8a4f
7f8fc971558219891ced425e8fe7a65d2a8f131f
572023f7b235679716c4e57c9d701d83444f14b8
36699ab480340b928f2e589d83a94e6786e1965b
ec86faa934cb31d97f738134547137f16d17c0d0
a69dc537cc1a6d3c3cb35d30197ed45914a150c3
1d9cb42c5654772efec1977957584a21763013a1
2feac451d2b4492aa8a67f40bd20dd351941d1a2
fdaf2d5885209634bf9d9f643cec5323efb4525c
d18572dd9a4ee3f66d205912edae4d87a58ec11f
89d85cde75143325205e332dd97bf1bb8402d7c1

4.0.0:

93aee84f575d46699f49af3c96194012527e0b22
cc425b5ddfe8f8474814f369409e637c36898542
5a0e75f0a9ad063ebaa7eb19b82104f00acb80a0
0015ca5cbabe0b31d31610ddfaafd90a9e5911a4
4882206430532af27aa2ffd30df2818e4661e981
09bd7ba9f5f7bd1c0cf62ba89731ae3cc6d1c72e
292fa230cb9ef7d2ca2a1db59f0ff843e538f075
9fd7e96aab30d219bceb67f768fed01bedf1199f
b5ec7de7b5111f898453f96bdfd095fc1d8f6e18
e6e40f80cdf37021deb8c4f4311724a64461a1d1

5.0.0:

b3e2bb9458af556cb8aa0558f59222f462b81069
1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3
30d2a17b46e9b2979e91f6d85c8b0da98879a879
b2ce76a0730e48e60633a698cd876d55917ac9bc
a1e8bd2f5c2a7b42b243c9422f3a86e530665e9f
68a86dc15ccdf0f1242dc71b3d8da18a3ee6b8be


Just need to turn into patches.

--js

Patch
diff mbox series

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 7033e531de..8b23e98474 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -341,14 +341,6 @@  they have no effect when used with @option{-n} to skip image creation.
 Silently ignored options can be confusing, so this combination of
 options will be made an error in future versions.
 
-@section Build system
-
-@subsection Python 2 support (since 4.1.0)
-
-In the future, QEMU will require Python 3 to be available at
-build time.  Support for Python 2 in scripts shipped with QEMU
-is deprecated.
-
 @section Backwards compatibility
 
 @subsection Runnability guarantee of CPU models (since 4.1.0)