qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"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>,
	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: Tue, 14 Feb 2023 14:17:52 +0000	[thread overview]
Message-ID: <Y+uYEKYQB+8kjtEx@redhat.com> (raw)
In-Reply-To: <CABgObfb-_upmc=36_bnxLMCB+0KqWoZNK62rnD5KpBKhW4N+hw@mail.gmail.com>

On Tue, Feb 14, 2023 at 03:03:54PM +0100, Paolo Bonzini wrote:
> On Tue, Feb 14, 2023 at 12:49 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > [quote]
> > The motivation for this series is that Python 3.6 was EOL at the end of
> > 2021; upstream tools are beginning to drop support for it, including
> > setuptools, pylint, mypy, etc. As time goes by, it becomes more
> > difficult to support and test against the full range of Python versions
> > that QEMU supports. The closer we get to Python 3.12, the harder it will
> > be to cover that full spread of versions.
> > [/quote]
> >
> > this is all about new/eol versions of software upstream, and I don't
> > think that's a justification. QEMU explicitly aims to use distro provided
> > versions and upstream EOL status is not relevant in that context. Even
> > if using "pip" to install it is possible to limit yourself to upstream
> > releases which still support 3.6.
> >
> > There is the separate issue of Meson dropping python 3.6 which motivates
> > Paolo's series. Again though, we don't have to increase our minimum meson
> > version, because meson is working today. It is our choice to to increase
> > it to use latest available meson features. At some point we can decide
> > what we have is good enough and we don't have to keep chasing the latest
> > features. Maybe we're not there yet, but we should think about when that
> > would be.
> 
> In the case of Meson, the main advantage is moving _all_ of the
> emulator configury out of the configure script.  This requires
> add_global_dependencies which was added in 0.63.  So in that case it
> is indeed mostly about shiny new features and it's not absolutely
> necessary.
> 
> In the case of Python the issue is not the interpreter per se, though
> there are a couple new feature in Python 3.7 that are quite nice (for
> example improved data classes[1] or context variables[2]). The main
> problem as far as I understood (and have seen in my experience) is
> linting tools. New versions fix bugs that caused false positives, but
> also become more strict at the same time. The newer versions at the
> same time are very quick at dropping support for old versions of
> Python; while older versions sometimes throw deprecation warnings on
> new versions of Python. This makes it very hard to support a single
> version of, say, mypy that works on all versions from RHEL8 and SLE15
> to Fedora 38 and Ubuntu 23.04.
> 
> [1] https://peps.python.org/pep-0557/
> [2] https://peps.python.org/pep-0567/
> 
> In fact this issue is the reason why RHEL9 does not package any of
> these tools and does not run them as part of building RPMs even though
> in principle it would be a good idea; it's too much of a pain to have
> a single version that works across all the packages in the
> distribution.
> 
> Regarding your other suggestion:
> 
> > * For non-native library/applications dependancies we aim
> >   to support only the most recent distro version. Users
> >   of older distros may need to dynamically fetch newer
> >   deps.
> 
> I think this is a good idea, but one issue with "only supporting the
> most recent distro version" is SUSE. While the most recent version of
> SLE is about 5 years old, there is no next version in sight---SUSE
> instead is working on their "Adaptable Linux Platform", but it's still
> in the prototype stage[3]. So alternatively we could put a 4 or 5 year
> cutoff after which you need to fetch newer deps. Considering the
> delays between freeze and release of distros like RHEL or SLE, in
> practice we would probably keep Python versions supported for 6-7
> years.

Yeah, that kind of problem with very old SUSE would push towards
simply excluding the LTS distros, or excluding them if they're
older than N years, and expect users of such old distros to
download newer python modules, etc.

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-14 14:18 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é
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é [this message]
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+uYEKYQB+8kjtEx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).