On Fri, Feb 10, 2023 at 04:32:19PM +0000, Peter Maydell wrote: > On Fri, 10 Feb 2023 at 16:01, John Snow <js...@redhat.com> wrote: > > On Fri, Feb 10, 2023, 5:41 AM Peter Maydell <peter.mayd...@linaro.org> > > wrote: > >> On Fri, 10 Feb 2023 at 00:31, John Snow <js...@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 :|
