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

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

On Thu, Jan 15, 2026 at 09:56:31PM +0100, Thomas Huth wrote:
> On 15/01/2026 19.01, 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>
> > ---
> ...
> > +
> > +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
> 
> I don't think that we run any test frameworks for Linux on mips64el or
> riscv64 in the CI, do we? It's only cross-compilation of the code.

I didn't want to put those in tier 3 since I think they're generally
better than that. Perhaps this bullet should be loosened slightly

   "May run some tests frameworks in CI"

> 
> ...
> > +
> > +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
> 
> You missed Haiku.

Opps, I knew I'd miss something :-)

> > +
> > +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
> 
> Support for 32-bit OSes is currently being removed.

Yep, this doc is slightly anticipating the future. I was expecting
that Richard's series:

  https://lists.nongnu.org/archive/html/qemu-devel/2026-01/msg03073.html

will be merged soon enough.

> > + * Any OS not listed above
> 
> Is it possible at all to compile QEMU for any other OS? I though our
> configure script would block such attempts...?

Hmm, true, we should be blocking atttempts to build. So anycode related
to unclassified OS would be non-buildable and definitely OK to remove.

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