From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"John Snow" <jsnow@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Cleber Rosa" <crosa@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Michael Roth" <michael.roth@amd.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
Qemu-block <qemu-block@nongnu.org>,
"Hanna Reitz" <hreitz@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>
Subject: Re: [PATCH v2 6/7] CI: Stop building docs on centos8
Date: Tue, 14 Feb 2023 11:48:55 +0000 [thread overview]
Message-ID: <Y+t1J72iMsLWXHne@redhat.com> (raw)
In-Reply-To: <87cz6cpue3.fsf@pond.sub.org>
On Tue, Feb 14, 2023 at 08:40:20AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> [...]
>
> > We don't have to drop python 3.6. It is a choice because
> > of a desire to be able to use some shiny new python
> > features without caring about back compat.
>
> I read this on Friday, and decided to let it sit until after the
> weekend. Well, it's now Tuesday, and to be frank, it's still as
> offensively flippant as it was on Friday. It shows either ignorance of
> or cavalier disregard for the sheer amount of work some of us have had
> to put into keeping old versions of Python viable.
>
> The latter would be quite unlike you, so it must be the former.
I'm sorry, I don't mean it to be offensive. I'm genuinely not seeing
from the descriptions in the series what the functional benefits are
from dropping 3.6.
> John has sunk *man-months* into keeping old versions of Python viable.
> I've put in a lot less myself, but still enough to be painfully aware of
> it. I figure Cleber and Beraldo are somewhere in between
>
> Insinuating John's proposal is motivated by "a desire to be able to use
> some shiny new python features without caring about back compat"
> disrespects all this work.
I'm writing my comments based on what is described in the cover letter
as the motivations for the change:
[quote]
The motivation for this series is that Python 3.6 was EOL at the end of
2021; upstream tools are beginning to drop support for it, including
setuptools, pylint, mypy, etc. As time goes by, it becomes more
difficult to support and test against the full range of Python versions
that QEMU supports. The closer we get to Python 3.12, the harder it will
be to cover that full spread of versions.
[/quote]
this is all about new/eol versions of software upstream, and I don't
think that's a justification. QEMU explicitly aims to use distro provided
versions and upstream EOL status is not relevant in that context. Even
if using "pip" to install it is possible to limit yourself to upstream
releases which still support 3.6.
There is the separate issue of Meson dropping python 3.6 which motivates
Paolo's series. Again though, we don't have to increase our minimum meson
version, because meson is working today. It is our choice to to increase
it to use latest available meson features. At some point we can decide
what we have is good enough and we don't have to keep chasing the latest
features. Maybe we're not there yet, but we should think about when that
would be.
[quote]
The qemu.qmp library and the avocado testing framework both have
motivations for dropping 3.6 support, but are committed to not doing so
until QEMU drops support.
[/quote]
I suspect that this is more of a driver for the drop of 3.6, but I
don't see any details.
IOW overall justification come across as wanting to use new features,
and follow upstream EOL, without any real detail of what we're going
to gain from a functional POV.
> We should have a sober discussion on which versions of Python to work
> with, and the tradeoffs involved. But before I engage in that, I insist
> on resetting the frame: no, this is not about shiny, new Python
> features. It is about stopping the bleeding. It is about reducing what
> feels more and more like bullshit work to me, so we can actually
> accomplish stuff that matters.
Every applications developer chooses an arbitrary cut off points for
minimum software versions, depending on their particular needs. With
our support policy we tried to express a reasonable tradeoff between
keeping back compat, and being able to adopt new features.
Obviously that tradeoff is not currently looking acceptable on the
python side, but it is not clear why that is ?
Can someone simply explain what we wil see as the benefit from dropping
3.6 / adopting 3.7 as the baseline ?
With 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 :|
next prev parent reply other threads:[~2023-02-14 11:49 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 0:31 [PATCH v2 0/7] Python: Drop support for Python 3.6 John Snow
2023-02-10 0:31 ` [PATCH v2 1/7] python: support pylint 2.16 John Snow
2023-02-10 0:31 ` [PATCH v2 2/7] python: drop pipenv John Snow
2023-02-10 0:31 ` [PATCH v2 3/7] configure: Look for auxiliary Python installations John Snow
2023-02-10 7:39 ` Thomas Huth
2023-02-10 10:45 ` Paolo Bonzini
2023-02-10 15:28 ` John Snow
2023-02-10 15:53 ` Peter Maydell
2023-02-10 16:17 ` Paolo Bonzini
2023-02-10 16:21 ` John Snow
2023-02-10 16:26 ` Paolo Bonzini
2023-02-10 19:56 ` Eric Blake
2023-02-10 0:31 ` [PATCH v2 4/7] configure: Add nice hint to Python failure message John Snow
2023-02-10 7:45 ` Thomas Huth
2023-02-10 19:19 ` John Snow
2023-02-10 0:31 ` [PATCH v2 5/7] DO-NOT-MERGE: testing: Add Python >= 3.7 to Centos, OpenSuSE John Snow
2023-02-10 0:31 ` [PATCH v2 6/7] CI: Stop building docs on centos8 John Snow
2023-02-10 7:06 ` Philippe Mathieu-Daudé
2023-02-10 10:41 ` Peter Maydell
2023-02-10 16:01 ` John Snow
2023-02-10 16:32 ` Peter Maydell
2023-02-10 16:51 ` Daniel P. Berrangé
2023-02-10 17:15 ` Peter Maydell
2023-02-10 18:27 ` Paolo Bonzini
2023-02-15 12:30 ` Daniel P. Berrangé
2023-02-14 7:40 ` Markus Armbruster
2023-02-14 8:35 ` Thomas Huth
2023-02-14 9:59 ` Alex Bennée
2023-02-14 12:10 ` Daniel P. Berrangé
2023-02-16 1:08 ` Markus Armbruster
2023-02-16 11:00 ` Daniel P. Berrangé
2023-02-14 10:33 ` Peter Maydell
2023-02-14 11:03 ` Kevin Wolf
2023-02-15 19:17 ` Markus Armbruster
2023-02-14 11:48 ` Daniel P. Berrangé [this message]
2023-02-14 14:03 ` Paolo Bonzini
2023-02-14 14:17 ` Daniel P. Berrangé
2023-02-14 17:26 ` Kevin Wolf
2023-02-14 20:52 ` Paolo Bonzini
2023-02-15 10:38 ` Kevin Wolf
2023-02-15 11:35 ` Daniel P. Berrangé
2023-02-16 1:46 ` Markus Armbruster
2023-02-16 11:06 ` Daniel P. Berrangé
2023-02-17 22:49 ` John Snow
2023-02-20 8:51 ` Markus Armbruster
2023-02-16 11:12 ` Daniel P. Berrangé
2023-02-16 10:40 ` Markus Armbruster
2023-02-10 17:55 ` John Snow
2023-02-10 18:09 ` Peter Maydell
2023-02-10 20:31 ` Paolo Bonzini
2023-02-10 0:31 ` [PATCH v2 7/7] Python: Drop support for Python 3.6 John Snow
2023-02-10 10:04 ` [PATCH v2 0/7] " Markus Armbruster
2023-02-14 18:35 ` John Snow
2023-02-15 10:53 ` Kevin Wolf
2023-02-15 19:05 ` Markus Armbruster
2023-02-16 10:17 ` Peter Maydell
2023-02-16 12:31 ` Markus Armbruster
2023-02-16 10:58 ` Thomas Huth
2023-02-17 9:06 ` Markus Armbruster
2023-02-17 9:56 ` Thomas Huth
2023-02-17 15:37 ` Peter Maydell
2023-02-17 15:41 ` Daniel P. Berrangé
2023-02-17 10:01 ` Daniel P. Berrangé
2023-02-17 20:46 ` John Snow
2023-02-20 6:16 ` Thomas Huth
2023-02-20 19:56 ` John Snow
2023-02-21 12:00 ` Thomas Huth
2023-02-17 11:37 ` Proposed way forward " Daniel P. Berrangé
2023-02-17 13:46 ` Thomas Huth
2023-02-17 13:52 ` Daniel P. Berrangé
2023-02-17 14:40 ` Paolo Bonzini
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=Y+t1J72iMsLWXHne@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@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).