Re: [PATCH v2 0/7] Python: Drop support for Python 3.6

[Markus Armbruster <armbru@redhat.com>]

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.