[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/7] Python: Drop support for Python 3.6
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v2 0/7] Python: Drop support for Python 3.6 |
Date: |
Fri, 17 Feb 2023 10:06:49 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Thomas Huth <thuth@redhat.com> writes:
> On 15/02/2023 20.05, Markus Armbruster wrote:
>> The discussion under PATCH 6 makes me think there's a bit of confusion
>> about the actual impact of dropping support for Python 3.6. Possibly
>> because it's spelled out in the commit message of PATCH 7. Let me
>> summarize it in one sentence:
>>
>> *** All supported host systems continue to work ***
>>
>> Evidence: CI remains green.
>
> The CI remains green since one of the patches disabled the building of the
> docs on CentOS 8. That's not how I'd describe "continue to work", at least
> not in the same extend as before.
Thus the exception ...
>> On some supported host systems, different packages need to be installed.
>> On CentOS 8, for instance, we need to install Python 3.8.13 or 3.9.16
>> instead of 3.6.8. Let me stress again: same repository, different
>> package. No downsides I can see.
... right here:
>> The *one* exception is Sphinx on CentOS 8. CentOS 8 does not ship a
>> version of Sphinx that works with Python 3.7 or newer. This series
>> proposes to simply stop building the docs there, unless the user
>> provides a suitable version of Sphinx (which is easy enough with pip).
>
> I think we've all understood that. The thing that you obviously did not
> understood: This breaks our support statement.
> I'm pretty sure that you could also build the whole QEMU suite successfully
> on an ancient CentOS 7 or Ubuntu 18.04 system if you manually install a
> newer version of GCC and some of the required libraries first. But that's
> not how we understand our support statement.
>
> Sure, you can argue that you can use "pip install" to get a newer version of
> Sphinx on RHEL 8 / CentOS 8 to continue building the docs there - but is
> that really that much different from installing a newer version of GCC and
> libraries on an ancient distro that we do not officially support anymore?
> I'd say no. You also have to consider that not every build host has access
> to the internet, maybe some companies only have an internal mirror of the
> distro packages in their intranet (I remember some discussion about such a
> case in the past) - so while you were perfectly fine to build the whole of
> QEMU on a CentOS 8 there before this change, you could now not build parts
> of QEMU anymore there due to the missing possibility to run "pip install"
> without full internet connection.
>
> And sure, you can argue that it's "just" the documentation. But IMHO that's
> still an essential part of the QEMU build, and it used to work before, so it
> feels wrong to cut that now out. And also, if we start with the
> documentation now, what's next? If for example scripts/shaderinclude.py
> stops working with Python 3.6, do we then simply say: "Oh, it's fine, you
> can still build all the other targets that work without this script, just
> not the ones anymore that need it"?
My view on all this is a bit more pragmatic.
For a human developer, the difference between "dnf install
python-sphinx" and "pip install sphinx" is, in my opinion, close to
negligible. Really no comparison to "git-clone GCC and bootstap it".
You seem to disagree with that.
For automated builds in general, and distro packaging in particular, the
difference is real, and could even be a show stopper. But who's
packaging bleeding edge QEMU on CentOS 8? I suspect the only automated
builds are our own CI, where the difference is real, but hardly a show
stopper. John's patch is the stupidest solution that could possibly
work for us: disable doc building on CentOS 8. Alternative solutions
have been proposed, and that's fair. Again, you seem to think this
issue is a lot more serious.
So maybe this breaks our support statement for a sufficiently rigid
interpretation of our support statement. Not the way interpreted it,
but if it's the way it is to be interpreted, I stand corrected.
But then I'd like us to be a bit more pragmatic. Is minor and graceful
degradation for systems close to the trailing edge really so
unacceptably terrible that we have to bend over backwards to avoid it?
>> All the angst about CentOS falling off the end of our "supported build
>> platforms" list is not actually warranted by this series :)
>
> Using the term "angst" for the concerns of your fellows here is quite
> cheeky. It's not about "angst", it's about a discussion that our support
> policy might need to be adjusted if we do this step. So instead of writing
> such sentences, I'd rather would like to see you posting a patch for
> docs/about/build-platforms.rst for constructive further discussion instead.
The phrasing of this sentence was ill-advised. If it caused offense, I
apologize.
- Re: [PATCH v2 3/7] configure: Look for auxiliary Python installations, (continued)
- [PATCH v2 7/7] Python: Drop support for Python 3.6, John Snow, 2023/02/09
- [PATCH v2 2/7] python: drop pipenv, John Snow, 2023/02/09
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Markus Armbruster, 2023/02/10
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, John Snow, 2023/02/14
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Markus Armbruster, 2023/02/15
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Daniel P . Berrangé, 2023/02/17
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, John Snow, 2023/02/17
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Thomas Huth, 2023/02/20
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, John Snow, 2023/02/20
- Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Thomas Huth, 2023/02/21
Proposed way forward Re: [PATCH v2 0/7] Python: Drop support for Python 3.6, Daniel P . Berrangé, 2023/02/17