Re: [PATCH] meson.build: Bump minimum supported version of pixman to 0.34.0

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

On Wed, May 11, 2022 at 12:56:45PM +0200, Thomas Huth wrote:
> On 11/05/2022 12.28, Peter Maydell wrote:
> > On Wed, 11 May 2022 at 10:50, Thomas Huth <thuth@redhat.com> wrote:
> > > 
> > > We haven't revisited the minimum required versions of pixman
> > > since quite a while. Let's check whether we can rule out some
> > > old versions that nobody tests anymore...
> > > 
> > > For pixman, per repology.org, currently shipping versions are:
> > > 
> > >       CentOS 8 / RHEL-8 : 0.38.4
> > >                Fedora 34: 0.40.0
> > >               Debian 10 : 0.36.0
> > >        Ubuntu LTS 20.04 : 0.38.4
> > >      openSUSE Leap 15.3 : 0.34.0
> > >             MSYS2 MinGW : 0.40.0
> > >           FreeBSD Ports : 0.34.0 / 0.40.0
> > >            NetBSD pksrc : 0.40.0
> > > 
> > > OpenBSD 7.1 seems to use 0.40.0 when running tests/vm/openbsd.
> > > 
> > > So it seems to be fine to bump the minimum version to 0.34.0 now.
> > 
> > This seems to be missing the rationale for why bumping
> > the minimum version is worth doing. What new feature that
> > we need is this enabling, or what now-unnecessary bug
> > workarounds does this permit us to drop?
> 
> We simply don't test such old versions anymore. Thus what happens if someone
> tries to use such a version and runs into a problem (especially if it is
> non-obvious and would need a lot of debugging)? Are you still willing to fix
> it? Or would you then rather bump the version after hours of debugging the
> problem? ... IMHO it's better to set the expectations right from the start.
> If we do not test and support it anymore, we should not give the impression
> that QEMU can still be compiled with this.

Support for QEMU is not such a clearly defined boundary, there are many
levels of support.  Our CI testing determines our "top tier" platforms
where we expect everything to be functional at all times, but it doesn't
mean that all other platforms are entirely unsupported. It merely means
we can't offer the same level of assurance that it will be perfect out
of the box.

If someone reports an issue we have freedom to decide how much effort
to put in. If they're using a pixman that's very old compared to what
we've tested, we don't have to spend time on that ourselves. We can
easily tell the reporter to reproduce with something newer first if
desired.

The platform support matrix is a way to determine:

 - what platforms we should focus our testing resources on

   For this, we can unambiguously bump our tsting envs
   on each release. It merely means the old version is
   no longer top tier, it is second tier in terms of
   what quality users can expect.

 - whether it is reasonable to bump a package minimum version

   Admittedly we never expressed whether the min version bumps
   are justifiable just for the sake of it, or whether version
   bumps are expected as a means to access new functionality /
   drop back compat code. Nearly all the bumps we've done have
   had some code benefit in the past.

   In practice when we bump the minimum glib2 version this has
   a clear code benefit, and once you bump min glib2, this defacto
   eliminates old versions of many other libraries. The only
   exception would be distros that are fast at rebasing glib, but
   slow at rebasing other deps we have. This is pretty uncommon
   for any mainstream distro.

IOW, I would suggest that in each release our first focus should
be on glib, gcc/clang versions, as those historically bring us
clear benefits. If glib bumps, then there's little point in
keeping any other deps with older min versions, so many other
bits can be a fairly straightforward decision.

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