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

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 09:35:44AM +0100, Thomas Huth wrote:
> On 14/02/2023 08.40, Markus Armbruster wrote:
> > Daniel P. Berrangé <berrange@redhat.com> writes:
> > 
> > [...]
> > 
> > > 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.
> > 
> > I read this on Friday, and decided to let it sit until after the
> > weekend.  Well, it's now Tuesday, and to be frank, it's still as
> > offensively flippant as it was on Friday.  It shows either ignorance of
> > or cavalier disregard for the sheer amount of work some of us have had
> > to put into keeping old versions of Python viable.
> 
> I'm a complete python ignorant, too, so I'm a little bit surprised of the
> amount of pain that these scripts are causing.
> 
> No matter of that fact, I think Peter still has a point that we have a real
> conflict here with our current support policy. So this either means that
> Python was the wrong choice for our needs (since it is moving too fast and
> causing too much friction), or we should really rethink our support policy.
> 
> I guess we're too deep into the Python rabbit hole already, and I'm not
> aware of any other good solutions (back to Perl scripts? No, thanks!), so
> it's likely quite impossible to tune that knob.

I still believe python is a probably the best thing for what we're using
it for. Certainly would not suggest shell or perl, and using a compiled
language would add its own complications for cross compilation.

> Thus we should maybe really start talking about our support policy now. I
> think the main problem is likely the sentence "Support for the previous
> major version will be dropped 2 years after the new major version is
> released". Maybe we should shorten that time frame to 1 year. The 2 years
> caused some confusions in the past already, since e.g. Debian only supports
> the previous major release for only one more year, and macOS also releases a
> major version each year ... so IMHO we could shorten the time frame for the
> previous major release to 1 year instead. People then could still continue
> building QEMU on CentOS 8, but they have to be aware that they might install
> other software like Sphinx manually if they want to continue using QEMU with
> docs there. What do you think?


I think perhaps the problem is not in the length of time defined by
our support policy, but rather that we're facing a rather different
reality to the one we've historically been used it, where distros
are no longer critical dependancies and our support policy does not
reflect that.


For any C/C++ application, wanting to target the versions shipped in a
distro has been pretty much normal practice. C has not ever come with
a standard package manager toolset, the distros service that role. The
distros also aren't generally a fan of shipping multiple versions of
C libs in parallel.


Pretty much every non-C library though is different. They all have
their own package manager service / tools (perl has cpan, pytyhon has
PyPi/pip, ruby has gems. With latest compiled languages like Go/Rust,
this has gone one step further and is natively integrated into the
compiler toolchain as standard.


IOW, for everything except C, it has become increasingly normal
practice to ignore the distro and dynamically download all the deps
your application needs into a self contained local environment.
Now, the distros aren't especially a fan of this new world, since
they still prefer to unbundle all these deps, but I think that
approach is increasingly difficult for them to achieve because the
majority of upstreams don't care for the distro versions.


Thus what we're experiancing is a clash between the traditional
way that C applications/libraries deal with their deps, vs the
way pretty much every other language deals with their deps in
the modern world. It has come up now because we're making much
more use of python now, than we did in the past.


Our support policy is written from the POV of the C world, and
merely reducing the length of time we support a distro does not
address the different world view of Python.

Should we instead try to be more explicit about the different
needs of the non-C dependencies ?

We could for example say

 * For native library/application dependancies we aim to
   support the two most recent distro versions, for 2 years
   overlap

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

The python 3.8 runtime would be considered a native dep, so fall
under the 2 distro versions rule. This is fine with CentOS 8,
since it provides newer python runtime versions.

The python libraries, or tools written in python (meson), would
fall under the second rule, and so only need to target one distro
version. This would be compatible with CentOS 8, as the users would
be expected to download extra python components (or we do it on
their behalf).

For the second rule, rather than saying most recent distro versions,
possibly we might want to carve out an exclusion for LTS distros too.
ie, explicitly don't care about versions of non-native bits in RHEL
at all, beyond availability of the base (python) runtime.


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