Re: [PATCH] docs/about: propose OS platform/arch support tiers

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

On Thu, Jan 15, 2026 at 12:48:56PM -0800, Pierrick Bouvier wrote:
> On 1/15/26 10:01 AM, Daniel P. Berrangé wrote:
> > Informally we have approximately three groups of platforms
> > 
> >   * Tier 1: fully built and fully tested by CI. Must always be
> >             kept working & regressions fixed immediately
> > 
> >   * Tier 2: fully built and partially tested by CI. Should
> >             always be kept working & regressions fixed quickly
> > 
> >   * Tier 3: code exists but is not built or tested by CI.
> >             Should not be intentionally broken but not
> > 	   guaranteed to work at any time. Downstream must
> > 	   manually test, report & fix bugs.
> > 
> > Anything else is "unclassified" and any historical code
> > remnants may be removed.
> > 
> > It is somewhat tricky to define unambiguous rules for each tier,
> > but this doc takes a stab at it. We don't need to cover every
> > eventuality. If we get the core points of view across, then it
> > at least sets the direction for maintainers/contributors/users.
> > Other aspects can be inferred with greater accuracy than today.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > 
> > This came out of the discussion about recent unnoticed breakage
> > in NetBSD builds and what maintainers are expected todo about
> > it (if anything)
> > 
> >    https://lists.nongnu.org/archive/html/qemu-devel/2026-01/msg02543.html
> > 
> >   docs/about/build-platforms.rst | 152 +++++++++++++++++++++++++++++++++
> >   1 file changed, 152 insertions(+)
> > 
> > diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
> > index e95784cdb5..950e164c02 100644
> > --- a/docs/about/build-platforms.rst
> > +++ b/docs/about/build-platforms.rst
> > @@ -171,3 +171,155 @@ Only 64-bit Windows is supported.
> >   .. _MacPorts: https://www.macports.org/
> >   .. _MSYS2: https://www.msys2.org/
> >   .. _Repology: https://repology.org/
> > +
> > +OS Support Tiers
> > +----------------
> > +
> > +While the QEMU code targets a number of different OS platforms, they don't
> > +all get the same level of support from the project. This applies to
> > +contributor & maintainer expectations, CI automation and requirements
> > +for merge gating.
> > +
> > +Tier 1
> > +~~~~~~
> > +
> > +These platforms attain the highest level of quality offered by
> > +the QEMU project.
> > +
> > + * Builds and all tests pass at all times in both git HEAD and releases
> > +
> > + * Builds for multiple build configuration are integrated in CI
> > +
> > + * Runs all available tests frameworks (unit, qtest, iotests, functional)
> > +   in CI
> > +
> > + * Merging code is gated on successful CI jobs
> > +
> > +This covers
> > +
> > + * Linux (x86_64, aarch64, s390x)
> > +
> > +Responsibilities:
> > +
> > + * Contributors MUST test submitted patches on one of Tier 1 platforms.
> > +
> > + * Contributors SHOULD test submitted patches on Tier 1 platforms
> > +   by running a GitLab CI pipeline in their fork.
> > +
> > + * Maintainers MUST request contributors to fix problems with Tier 1
> > +   platforms.
> > +
> > + * Maintainers MUST test pull requests on Tier 1 platforms
> > +   by running a GitLab CI pipeline in their fork.
> > +
> > + * Maintainers MUST co-ordinate fixing regressions identified
> > +   post-merge immediately.
> > +
> > +
> > +Tier 2
> > +~~~~~~
> > +
> > +These platforms are considered to be near Tier 1 level, but are
> > +lacking sufficient automated CI testing cover to guarantee this.
> > +
> > + * Builds and all tests pass at all times in both git HEAD and releases
> > +
> > + * Builds for multiple build configuration are integrated in CI
> > +
> > + * Runs some test frameworks in CI
> > +
> > +This covers
> > +
> > + * Linux (mips64el, ppc64el, riscv64)
> > +
> > + * FreeBSD (x86_64)
> > +
> > + * macOS (aarch64)
> > +
> > + * Windows (x86_64)
> > +
> > +Responsibilities:
> > +
> > + * Contributors MAY test patches on Tier 2 platforms
> > +   by running a GitLab CI pipeline in their fork
> > +
> > + * Maintainers SHOULD request contributors to fix problems with Tier 2
> > +   platforms.
> > +
> > + * Maintainers MUST test pull requests on all Tier 2 platforms,
> > +   by running a GitLab CI pipeline in their fork.
> > +
> > + * Maintainers MUST co-ordinate fixing regressions identified
> > +   post-merge quickly.
> > +
> > +
> > +Tier 3
> > +~~~~~~
> > +
> > +These platforms have theoretical support in the code, but have
> > +little, or no, automated build and test coverage. Downstream
> > +consumers (users or distributors) who care about these platforms
> > +are requested to perform manual testing, report bugs and provide
> > +patches.
> > +
> > + * Builds and tests may be broken at any time in Git HEAD and
> > +   releases
> > +
> > + * Builds are not integrated into CI
> > +
> > + * Tests are not integrated into CI
> > +
> > + * Merging code is not gated
> > +
> > +This covers:
> > +
> > + * NetBSD
> > + * OpenBSD
> > + * macOS (except aarch64)
> > + * FreeBSD (except x86_64)
> > + * Windows (except x86_64)
> > + * Solaris
> > +
> > +Responsibilities:
> > +
> > + * Contributors MAY test patches on Tier 3 platforms manually
> > +
> > + * Maintainers MAY request contributors to fix problems
> > +   on Tier 3 platforms
> > +
> > + * Maintainers MAY test patches on Tier 3 platforms manually
> > +
> > + * Maintainers SHOULD NOT accept patches that remove code
> > +   targetting Tier 3 platforms even if currently broken
> > +
> > + * Downstream vendors SHOULD test RC releases on Tier 3 platforms
> > +   and provide bug reports and patches to address problems
> > +
> > +Note: if a Tier 3 platform is found to be significantly broken,
> > +no patches are contributed for a prolonged period, and there is
> > +no sign of downstream usage, it is liable to be moved to
> > +"Unclassified" and thus be subject to removal.
> > +
> > +
> > +Unclassified
> > +~~~~~~~~~~~~
> > +
> > +These platforms are not intended to be supported in the code
> > +and outside the scope of any support tiers.
> > +
> > +  * Code supporting these platforms can removed at any time
> > +  * Bugs reports related to these platforms will generally
> > +    be ignored
> > +
> > +This covers:
> > +
> > + * All 32-bit architectures on any OS
> > + * Any OS not listed above
> > +
> > +Responsibilities:
> > +
> > + * Maintainers MAY decline patches that add code targetting
> > +   unclassified platforms
> > +
> > + * Maintainers MAY accept patches that remove code targetting
> > +   unclassified platforms
> 
> That's a good summary, but it should differentiate testing/runtime issues
> from building issues.
> 
> In general, maintainers should ensure code build on all platforms/configs.
> Of course, it's a best effort considering not all of them are built in CI,
> but in case a build issue is caught on time, it should be fixed before
> hitting master.

It is certainly the case for Tier 1/2 platforms, that a known build
issue must not be willfully merged into master.

That's not the case for Tier 3, since we can't guarantee that the QEMU
code builds successfully to begin with. If we do a see a probable issue
in a Tiar 3 platform build, and its easy to resolve then we should. We
can't gate on every Tier 3 problem given the lack of guaranteed working
dev/test envs and lack of CI.

Ideally we should not have any platforms listed under Tier 3 at all,
but today we do. May be some will graduate to Tier 2 at some point.

> It may be worth to mention that all platforms can be accessed for free
> using: https://github.com/second-reality/github-runners.
> If you're open to it, we could move this project under
> https://github.com/qemu and preinstall all dependencies on each runner, so
> people can easily jump on a shell and start debugging things without wasting
> time.

I don't speak for all maintainers, but personally I've no desire
to increase use of github for QEMU, or indeed any other projects.

The choice of platform is about more than just possible features.
The ability to control our own destiny, and maintain use of OSS
infrastructure was/is important.

GitLab is certainly not perfect, but gitlab.com was an acceptable
tradeoff with the ability to switch to self-hosted Gitlab since
it is based on OSS. Beyond that we could also migrate to Forgejo/
Codeberg. Tieing ourselves into GitHub's fully proprietary service
has never really been on the table for QEMU.

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