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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jul 02, 2025 at 03:24:09PM -0400, Paolo Bonzini wrote:
> 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, 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.
> 
> 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.

Note that much of the commentary about distros versions has been in
relation to the distro packagers, but that was not my only target
in writing the distro policy. It was equally aimed at contributors
using such distros, as well as 3rd party vendors building solutions
on top of designated distro versions

You can say contributors should just pick newer containers for their
build env, or manually download newer deps, or have QEMU build fancy
scripts to auto-download newer deps. All of those options have a cost
to them, as compared to using what is already present in the distro.

In terms of 3rd party vendors, they can have similar roles to a distro
vendor, but are more likely to package up newer QEMU versions to run
on pre-existing distros.

A further goal of the support policy was to provide a mechanism to
eliminate exactly these kind of mail threads. Before we had the policy,
every single time someone wanted to bump the min version of any dep
we would have debates over whether it was OK or not, there was always
someone who wanted the old version of the distro forever.  Defining
the policy has allowed us to unconditionally bump the min versions of
our times on a usually reasonable timeframe, without needing to engage
in debate. We can just point people to our support policy when they
complained that they really wanted old versions X, Y, & Z.

Every time we make an exception to the policy, we undermine the benefits
we obtain from it, taking us back the old world where our min versions
were an inconsistent & arbitrary set, with little clear understanding
of when we would change, either by maintainers or users.


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