Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Peter Maydell]

On Fri, 10 Feb 2023 at 16:52, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Feb 10, 2023 at 04:32:19PM +0000, Peter Maydell wrote:
> > On Fri, 10 Feb 2023 at 16:01, John Snow <jsnow@redhat.com> wrote:
> > > On Fri, Feb 10, 2023, 5:41 AM Peter Maydell <peter.maydell@linaro.org> 
> > > wrote:
> > >> On Fri, 10 Feb 2023 at 00:31, John Snow <jsnow@redhat.com> wrote:
> > >> This confuses me. We work fine with Python 3.6 today.
> > >
> > >
> > > That won't last - Many tools such as mypy, pylint and flake8 which I use 
> > > to manage our python codebase have been dropping support for 3.6 and I've 
> > > had to implement an increasing number of workarounds to help keep it 
> > > possible to test 3.6 via CI while also ensuring our newest platforms work 
> > > as dev environments.
> >
> > Something somewhere seems kind of out-of-sync here. Either:
> >  * Python is deprecating old versions too quickly and
> >    dropping support for them too fast
>
> Nope, they're fine in declaring EOL whenever they like. There's
> no requirement for upstreams to support arbitrary old versions
> for any length of time.

To be clear, yes, absolutely any other software project can
set whatever lifecycle it chooses to do, and similarly distros
can do what they wish to do. But somewhere along the line
something's gone sideways here, because all these choices
people are making seem reasonable and yet here we are :-)
I put this bit in here because one response to "upstream's
idea of how long it wants to support something is very short"
would be "this isn't a dependency that it's suitable for
QEMU as a project to have, because the mismatch is too great".
(This would obviously be super-painful in this specific case...)

> >  * CentOS is retaining old versions of Python when it needs to
> >    ship newer ones
>
> It is also totally OK for an distro to ship and support software
> versions which are EOL upstream. In fact for enterprise distros
> you can generally assume that *all* the software versions they
> ship are probably EOL or nearly so. The main value of enterprise
> distros is that they provide long term support, where upstreams
> are not willing to.

But we as a project also have the choice, if it seems to us
that Distro X is shipping absolutely ancient versions of
dependencies, to say "we don't support distro X, because its
life cycle policies are too far out of sync with ours", or to
say "you're going to need to provide the dependencies
yourself, here's a suggestion". (We effectively do that
already with macos and Windows.)

> >  * Our policy for what distros we support is overly lax
> >    and causing us to try to support ancient platforms
> >    that we shouldn't be trying to support
>
> I don't think so. Users of distros are not anywhere near
> as aggressive at updating their installations as users
> are. The number of users of RHEL-8 will dwarf that of
> RHEL-9 by a large margin for a decent amount of time
> yet.

Right. All of these things together seem to say:
 * Python is not an unreasonable thing for the project
   to depend on
 * CentOS 8 is not an unreasonable distro for us to
   want to continue to support
 * Therefore we should continue to work with the Python
   that ships with CentOS 8...

[snip]

> 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.
>
> Similarly we don't have to use the new meson which drops
> support for python 3.6, it is again a choice because we
> want to rely on some new meson features.
>
> QEMU could easily carry on supporting python 3.6 until
> the affected distros drop out ofo our support matrix, but
> we would have to opt out of using certain new features,
> or put more effort into back compat.
>
> Personally I'm still on the side of carrying on supporting
> 3.6 per our distro support policy, but if broad consensus
> is to drop 3.6 I'm not going push back anymore.

This is really where I'm at as well -- we set our distro
support policy, and we know that means that sometimes
we have to deal with continuing to support older versions
of dependencies even when it might be easier for us if we
could require newer versions. I'm reluctant to say that
Python gets a special derogation from that policy.

thanks
-- PMM