Re: Build platform guarantees, docs, tests, and snakes in the garden

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il mer 2 lug 2025, 15:24 Paolo Bonzini <pbonzini@redhat.com> ha scritto:
>
>>
>>
>> Il mar 24 giu 2025, 02:45 Markus Armbruster <armbru@redhat.com> ha
>> scritto:
>>
>>> > ... I think I value this a bit higher than Markus, but not really
>>> > because of offline builds.  Rather, keeping the "accepted" key lower (i.e.
>>> > supporting the packaged sphinx on a wide range of distros) makes it easier
>>> > to bump the "installed" key when needed, as in this failure to run 5.3.0
>>> > under Python 3.13.
>>>
>>> Showing my ignorance again...  I don't understand how keeping "accepted"
>>> lower helps.
>>>
>>
>> Because it makes it easier to use distro Python. If distro Python is
>> <accepted,
>>
>
> Sorry: if distro *sphinx* is <accepted.
>
> Paolo
>
>> configure's will try to use the "installed" version. If that version in
>> turn is too new for distro Python, you're screwed. So you want to be as
>> conservative as needed for accepted, but not more.

So, we get into trouble when accept the distro versions for some, but
not all depenencies, and end up with a mix of "accepted" and "installed"
versions that doesn't play together.

Ways to avoid this scenario:

* Ensure the "installed" version play with all the "accepted" versions
  of everything else.  I.e. as we move "installed" up, "accepted" needs
  to move up as well.

* We keep "accepted" for everything low enough so that we don't fall
  back to "installed" on any distro we care about.  Feels brittle.

Any others?

>> Regarding fool or pioneer: for sure we're extraordinarily kind towards
>> distros. To some extent we have to do that because of 1) the possible
>> competition of other VMMs that completely ignore distros (e.g. because they
>> just use cargo)—packaging is an area where C still has an edge and we want
>> to keep that edge 2) we're an infrastructure component that can't just tell
>> users to grab a flatpak.
>>
>> The distro policy (mostly conceived by Dan) has served us well, with only
>> small adjustments needed to have newish version of Meson/Rust(*), and
>> non-prehistoric versions of Python. I don't see a need to change it, since
>> at this point we have the tools needed to manage the complexity.

One of the "tools" being John Snow, I'm afraid.  Making the full Sphinx
version range work was impressive (and expensive!) work.  I take a
rather dim view on this kind of expensive heroics.  If John gets run
over by a bus, our hand may well be forced: I can't maintain the result
of his heroism, that's for sure.

>> Paolo
>>
>> (*) Most of the Rust issues would solve themselves by telling users of
>> Ubuntu 22.04 and Debian bookworm to install the upstream tool chain with
>> rustup instead of relying on distro rustc packages. Unlike Linux, which
>> uses unstable features, QEMU sticks to what's been stabilized and that
>> means newer releases sometimes.
>>
>> > This time there was a version that works on both the oldest and newest
>>> Python that we support, but there may not always be one because sphinx is
>>> all too happy at dropping support for EOL'd versions of Python.
>>>
>>> Pretty strong hint we shouldn't try to support EOL'd versions of Python
>>> either.
>>>
>>> > Paolo
>>> >
>>> >> Before I throw my weight behind any given option, I just want to know
>>> >> what we consider our non-negotiable obligations to be.
>>> >>
>>> >> Thanks,
>>> >> --js