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

[Daniel P . Berrangé]

On Thu, Feb 16, 2023 at 02:08:33AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> > 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.
> 
> Who does the fetching, users manually, or the build process
> automatically?

I expect both cases need supporting.

In the case of distro builds, they will have to fetch the
deps ahead of time, because the build environments usually
won't have any network access. Some contributors have also
previously objected to the build system fetching stuff off
the network, but they're a small minority.

For friendliness to developers, the build process would be
best to fetch automatically, if they haven't been provided
upfront.

> > 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.
> 
> Interesting idea.  Can anyone think of reasons not to do this?

It is probably even more compelling when looking at SLES, which is
having an even larger gap between releases than RHEL does.

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