From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Jani Nikula <jani.nikula@intel.com>,
Jonathan Corbet <corbet@lwn.net>, Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Masahiro Yamada <masahiroy@kernel.org>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org,
Jon Hunter <jonathanh@nvidia.com>
Subject: Re: [PATCH] docs: document python version used for compilation
Date: Fri, 10 May 2024 12:39:11 +0100 [thread overview]
Message-ID: <20240510123911.34f050b5@sal.lan> (raw)
In-Reply-To: <CAA8EJprcjDnpsriXOrRO4cVh5Sm9KDbHbsyKePru=6pn0-bfJA@mail.gmail.com>
Em Fri, 10 May 2024 13:39:17 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> escreveu:
> On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
> >
> > On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > Em Fri, 10 May 2024 11:08:38 +0300
> > > Jani Nikula <jani.nikula@intel.com> escreveu:
> > >
> > >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > >> > The drm/msm driver had adopted using Python3 script to generate register
> > >> > header files instead of shipping pre-generated header files. Document
> > >> > the minimal Python version supported by the script.
> > >> >
> > >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > >> > ---
> > >> > Documentation/process/changes.rst | 1 +
> > >> > 1 file changed, 1 insertion(+)
> > >> >
> > >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > >> > --- a/Documentation/process/changes.rst
> > >> > +++ b/Documentation/process/changes.rst
> > >> > @@ -63,6 +63,7 @@ cpio any cpio --version
> > >> > GNU tar 1.28 tar --version
> > >> > gtags (optional) 6.6.5 gtags --version
> > >> > mkimage (optional) 2017.01 mkimage --version
> > >> > +Python (optional) 3.5.x python3 --version
> > >>
> > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> > >> using anything older than the oldest supported version of Python,
> > >> i.e. 3.8 at this time?
> > >
> > > What's the point of breaking compilation with on older distros?
> > > The idea of minimal versions here is to specify the absolute minimum
> > > version that it is required for the build to happen. If 3.5 is
> > > the minimal one, then be it.
> >
> > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> > at least be aware *why* we'd be sticking to old versions.
>
> From my side, the 3.5 was chosen basing on the previous feedback from
> Jon Hunter: https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonathanh@nvidia.com/
Patch there seems small/simple enough if it is all it takes for 3.5.
Yet, it would be nice to hear from Jon Hunter about the rationale
for 3.5 support (if any).
> > Minimum versions here also means sticking to features available in said
> > versions, for Python just as well as for GCC or any other tool. That's
> > not zero cost.
> >
> > I guess there are two angles here too. The absolute minimum version
> > currently required, and the, uh, maximum the minimum version can be
> > safely bumped to. Say, you want to use a feature not available in the
> > current minimum, how far up can you bump the version to?
> >
> > Could we define and document the criteria (e.g. based on distros as you
> > suggest below) so we don't have to repeat the discussion?
Agreed. While we should not bump version randomly, defining a
criteria about when we should update the requirement sounds a great idea.
For me, the criteria is:
- the minimal version shall be at least the minimal one required for the
Kernel to build at the most used LTS distros that are not EOL, e. g.:
Debian, openSUSE/SUSE, CentOS/RHEL and Ubuntu LTS[1].
[1] In practice, Ubuntu LTS usually has a python version newer than
Debian LTS, and CentOS versions are identical to RHEL ones, so
I guess checking for Debian, openSUSE, SUSE and RHEL should be
enough.
Regards,
Mauro
next prev parent reply other threads:[~2024-05-10 11:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 13:31 [PATCH] docs: document python version used for compilation Dmitry Baryshkov
2024-05-09 16:48 ` Jonathan Corbet
2024-05-09 18:59 ` Abhinav Kumar
2024-05-30 17:06 ` Thierry Reding
2024-05-31 7:33 ` Geert Uytterhoeven
2024-05-31 8:19 ` Dmitry Baryshkov
2024-05-31 9:11 ` Thierry Reding
2024-05-10 8:08 ` Jani Nikula
2024-05-10 9:20 ` Mauro Carvalho Chehab
2024-05-10 10:09 ` Jani Nikula
2024-05-10 10:39 ` Dmitry Baryshkov
2024-05-10 11:21 ` Mauro Carvalho Chehab
2024-05-10 11:39 ` Mauro Carvalho Chehab [this message]
2024-05-10 11:47 ` Jon Hunter
2024-05-10 20:04 ` Rob Clark
2024-05-30 17:07 ` Thierry Reding
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=20240510123911.34f050b5@sal.lan \
--to=mchehab@kernel.org \
--cc=corbet@lwn.net \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=masahiroy@kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=workflows@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).