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

[Daniel P . Berrangé]

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.

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

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

The challenge here is that upstream developers want to
use shiny new features from latest upstream, and at the
same time don't want to keep back compat with older
versions that users see in their real world deployed
distros, because that is a burden.

Ideally upstream developers would never care about old
versions and only ever target the very latest upstream.
Meanwhile for users, apps would ideally support every
version of every OS that's ever existed.

Somewhere in the middle we have to strike a bargain
that spreads the pain fairly between the two groups,
accepting that this is going to be a burden for both
to some degre. Our distro support policy is a decent
attempt at doing that IMHO and has worked pretty well
IMHO.


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.

> because "use the system version of foo" should not be a big
> deal -- it's not like we're trying to support decades-old
> hosts here: Centos 8 was released in 2019, which is less than
> five years ago.

Yeah, it isn't very old at all, and in terms of deployments
will dominate over CentOS/RHEL 9 users.

> > The argument I'm making is:
> >
> > - CentOS 8 is a supported build platform
> > - All platforms *do* have a Python modern enough to allow us to drop 3.6
> > - CentOS's repo version of sphinx is hardcoded to use the older 3.6, though
> > - You expressed a preference to me in the past to NOT use a pip installed 
> > version of sphinx in preference to the system version in "configure"
> > - It's still possible to build docs on CentOS 8 after this patchset, you 
> > just need a pip version.
> > - We've used the justification that our build platform promise does not 
> > necessarily extend to docs and tests in the past.
> > - So just skip docs building for CentOS 8, only in the CI.
> >
> > If you believe docs in CI for CentOS 8 is a hard deal breaker, then I want 
> > to go back to discussing the possibility of using sphinx versions from pip.
> 
> If Python 3.6 is EOL, shouldn't CentOS have shipped an updated
> version of Sphinx to go with their updated Python ?

CentOS isn't dropping python 3.6 support. It will exist for the
lifetime of CentOS 8.

It just decided to also ship some newer python versions as an
opt-in. These newer python versions are just the minimal runtime
though. CentOS is not shipping all the add-on python modules it
has with 3.6.

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