Re: [RFC PATCH] docs/about/build-platforms: Refine the distro support policy

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 17/02/2023 16.06, Daniel P. Berrangé wrote:
>> On Fri, Feb 17, 2023 at 02:26:31PM +0100, Thomas Huth wrote:
> ...
>> I'm also not so comfortable dropping the only version of SLES that we
>> explicitly target, when we don't know when their new major release
>> will arrive.
>
> Let's hope that the next major version will show up at least five
> years after the previous one ... but what if it takes many more years?
> Do we want to support very old long term distros for "almost forever"?
>
> Also, should we maybe at least limit the time to 5 years? Otherwise,
> if openSUSE 16 gets released 5 years after v15, we have to support v15
> for 7 years in total due to the "two more years" rule...

Let's keep in mind that "2 years after the new major version" isn't the
law, it's a rule we give ourselves so we don't have to debate from first
principles every time.  If supporting a major version of SLES (or
anything for that matter) according to the rule becomes too expensive,
we can and should change the rule.

>> If we allow compilers, libraries to be bumped, then someone stuck on
>> RHEL-8 has a significant task to build their own toolchain/libraries
>> in order to work with QEMU still. If we only allow python modules to
>> be bumped, the solution is just a pip install / virtualenv away.
>
> Honestly, being a Python ignorant, I'm more comfortable with
> "./configure && make && make install" instead of messing up my system
> with pip like I did in the past ... but I guess it's ok if it is
> properly done automatically under the hood with a venv ... I'll get
> used to it ;-)

"pip in venv" should not mess up your system.

Automation is of course welcome, and likely to reduce mess-ups through
incorrect use / non-use of venvs.

Optional dependencies default to off when not satisfied.  Without
automation, satisfying them is up to the developer.  When you're not
hacking on Python code yourself, there is no need for you to satisfy the
mypy dependency, be it with dnf, pip, or whatever.

I believe the one Python-related dependency of general interest right
now is Sphinx, which is required for building documentation.