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

[Daniel P . Berrangé]

On Fri, Feb 10, 2023 at 07:27:41PM +0100, Paolo Bonzini wrote:
> On 2/10/23 18:15, Peter Maydell wrote:
> There are four possibilities:
> 
> * we change the support policy and stop supporting CentOS 8 and SLE 15, not
> a good idea since a lot of people have not migrated to CentOS 9 yet.
> 
> * we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
> supported.  This means several more years since SLE 16 hasn't even been
> released.

The massive gap from SLE 15 to 16 is something our support policy
wasn't anticipating, though it probably should have done, since a
4-5 year gap is actually normal if looking at previous SLE versions.

I was thinking too much about RHEL which has a short 3 year gap,
but also rebases software versions in .y releases, so often the
dependancies aren't as old as the 3 year life of RHEL would
suggest.

We need to finese our support policy to give us more flexibility
wrt the very long life / long gap enterprise distros.

> * we support Python 3.6 just for building documentation, i.e. we are careful
> not to use Python 3.7+ features in our Sphinx extensions but are free to use
> them elsewhere.  CentOS 8 users can install sphinx from either RPMs (which
> will use Python 3.6) or pip (which will use Python 3.8).
> 
> * we only support Python 3.7+, which means CentOS 8 CI and users have to
> either install Sphinx from pip or disable documentation.
> 
> The only difference between the last two is documentation and CI
> configuration.  The code is exactly the same.

While it is good to mention the idea of 3.6 just for docs, I don't
think it is really a good idea to put into practice.

IMHO there's compelling benefit in having a clear & simple story for
the min versions of dependancies, both for us as maintainers, and
for people consuming it. So if we want 3.7, we should apply it
universally without caveats / carve-outs.

> > I'm reluctant to say that
> > Python gets a special derogation from that policy.
> 
> Note that its not the Python runtime but the Python dependencies, for which
> we already install avocado and some Python development tools in a virtual
> environment.  So, the questions are:
> 
> * to what extent can we rely on pip packages (preinstalled by the user)
> instead of the distro packages?
> 
> * to what extent should QEMU install its own dependencies via pip in a
> virtual environment instead of requiring the user to preinstall them?

FWIW, when I introduced scripts/git-submodule.sh script to handle
automatically checking out git submodules during build, there was
quite a bit of negative feedback from some users/contributors who
don't want  stuff being fetched off the net during builds.

Typically their scenario was that they have a QEMU checkout on
one machine with net access. That filesystem was exported to
another machine (or multiple other machines) to perform the
actual build(s) and those build machines lacked net access.

This motiviated the introduction of the configure arg, to tell
us *NOT* to attempt to checkout submodules, but merely validate
that they exist at the right checkout hash. The user would
manually checkout the submodules on the hosts which had net
access.

This situation is not too dis-similar to what distros have in
their package build systems which often block net access.

None of this means we can't use a private virtualenv for all of
QEMU python bits.

Just that if we go this route, then we're putting a greater
burden on people whose distro doesn't have the required packages,
and whose build env lacks net access.

They'll have to populate a venv manually in some way and get it
onto their build env.  The number of people with this situation
though likely is small enough, that it is likely an acceptable
burden / tradeoff in general.  The burden would only apply to the
pieces of build that are actually mandatory for build, the most
prominent of which are meson, and the QAPI generation code. Bits
like avocado, mypy, flake8, etc are all optional extra tests.


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