All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "John Snow" <jsnow@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Beraldo Leal" <bleal@redhat.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Kevin Wolf" <kwolf@redhat.com>
Subject: Re: [PATCH v2 6/7] CI: Stop building docs on centos8
Date: Fri, 10 Feb 2023 16:51:53 +0000	[thread overview]
Message-ID: <Y+Z2Kcq17HGWuoTV@redhat.com> (raw)
In-Reply-To: <CAFEAcA_eGvz_BQVLhVWtedRh2mcBuMEhv0RKF+6DW4t+9FdPAw@mail.gmail.com>

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



  reply	other threads:[~2023-02-10 16:52 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  0:31 [PATCH v2 0/7] Python: Drop support for Python 3.6 John Snow
2023-02-10  0:31 ` [PATCH v2 1/7] python: support pylint 2.16 John Snow
2023-02-10  0:31 ` [PATCH v2 2/7] python: drop pipenv John Snow
2023-02-10  0:31 ` [PATCH v2 3/7] configure: Look for auxiliary Python installations John Snow
2023-02-10  7:39   ` Thomas Huth
2023-02-10 10:45   ` Paolo Bonzini
2023-02-10 15:28     ` John Snow
2023-02-10 15:53       ` Peter Maydell
2023-02-10 16:17       ` Paolo Bonzini
2023-02-10 16:21         ` John Snow
2023-02-10 16:26           ` Paolo Bonzini
2023-02-10 19:56       ` Eric Blake
2023-02-10  0:31 ` [PATCH v2 4/7] configure: Add nice hint to Python failure message John Snow
2023-02-10  7:45   ` Thomas Huth
2023-02-10 19:19     ` John Snow
2023-02-10  0:31 ` [PATCH v2 5/7] DO-NOT-MERGE: testing: Add Python >= 3.7 to Centos, OpenSuSE John Snow
2023-02-10  0:31 ` [PATCH v2 6/7] CI: Stop building docs on centos8 John Snow
2023-02-10  7:06   ` Philippe Mathieu-Daudé
2023-02-10 10:41   ` Peter Maydell
2023-02-10 16:01     ` John Snow
2023-02-10 16:32       ` Peter Maydell
2023-02-10 16:51         ` Daniel P. Berrangé [this message]
2023-02-10 17:15           ` Peter Maydell
2023-02-10 18:27             ` Paolo Bonzini
2023-02-15 12:30               ` Daniel P. Berrangé
2023-02-14  7:40           ` Markus Armbruster
2023-02-14  8:35             ` Thomas Huth
2023-02-14  9:59               ` Alex Bennée
2023-02-14 12:10               ` Daniel P. Berrangé
2023-02-16  1:08                 ` Markus Armbruster
2023-02-16 11:00                   ` Daniel P. Berrangé
2023-02-14 10:33             ` Peter Maydell
2023-02-14 11:03             ` Kevin Wolf
2023-02-15 19:17               ` Markus Armbruster
2023-02-14 11:48             ` Daniel P. Berrangé
2023-02-14 14:03               ` Paolo Bonzini
2023-02-14 14:17                 ` Daniel P. Berrangé
2023-02-14 17:26                 ` Kevin Wolf
2023-02-14 20:52                   ` Paolo Bonzini
2023-02-15 10:38                     ` Kevin Wolf
2023-02-15 11:35                     ` Daniel P. Berrangé
2023-02-16  1:46                       ` Markus Armbruster
2023-02-16 11:06                         ` Daniel P. Berrangé
2023-02-17 22:49                   ` John Snow
2023-02-20  8:51                     ` Markus Armbruster
2023-02-16 11:12                 ` Daniel P. Berrangé
2023-02-16 10:40               ` Markus Armbruster
2023-02-10 17:55         ` John Snow
2023-02-10 18:09           ` Peter Maydell
2023-02-10 20:31             ` Paolo Bonzini
2023-02-10  0:31 ` [PATCH v2 7/7] Python: Drop support for Python 3.6 John Snow
2023-02-10 10:04 ` [PATCH v2 0/7] " Markus Armbruster
2023-02-14 18:35 ` John Snow
2023-02-15 10:53   ` Kevin Wolf
2023-02-15 19:05 ` Markus Armbruster
2023-02-16 10:17   ` Peter Maydell
2023-02-16 12:31     ` Markus Armbruster
2023-02-16 10:58   ` Thomas Huth
2023-02-17  9:06     ` Markus Armbruster
2023-02-17  9:56       ` Thomas Huth
2023-02-17 15:37         ` Peter Maydell
2023-02-17 15:41           ` Daniel P. Berrangé
2023-02-17 10:01       ` Daniel P. Berrangé
2023-02-17 20:46     ` John Snow
2023-02-20  6:16       ` Thomas Huth
2023-02-20 19:56         ` John Snow
2023-02-21 12:00           ` Thomas Huth
2023-02-17 11:37 ` Proposed way forward " Daniel P. Berrangé
2023-02-17 13:46   ` Thomas Huth
2023-02-17 13:52     ` Daniel P. Berrangé
2023-02-17 14:40   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+Z2Kcq17HGWuoTV@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.