| Message ID | 20220511094758.794946-1-thuth@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | meson.build: Bump minimum supported version of pixman to 0.34.0 | expand |
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 shouldn't bump minimum versions of libraries only because all our supported hosts happen to have something newer. thanks -- PMM
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. Thomas
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
diff --git a/meson.build b/meson.build index 864e97945f..7843a50cc1 100644 --- a/meson.build +++ b/meson.build @@ -504,7 +504,7 @@ if 'ust' in get_option('trace_backends') endif pixman = not_found if have_system or have_tools - pixman = dependency('pixman-1', required: have_system, version:'>=0.21.8', + pixman = dependency('pixman-1', required: have_system, version:'>=0.34.0', method: 'pkg-config', kwargs: static_kwargs) endif zlib = dependency('zlib', required: true, kwargs: static_kwargs)
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. Signed-off-by: Thomas Huth <thuth@redhat.com> --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)