The wikis are now using the new authentication system.
If you did not migrate your account yet, visit

openSUSE:OpenSUSE Distribution Tiers Policy

Jump to: navigation, search

THIS PAGE IS FINAL DRAFT - please participate in opensuse-factory@ discussion before July 10th 2020!

Version: 20200703

What is an openSUSE distribution primary architecture?


Before this policy, the openSUSE Tumbleweed distribution primary architectures, which are the architectures that development, test and release are targeting, were i586 and x86_64. For openSUSE Leap distribution the primary architecture had been x86_64.

This document describes the responsibilities that come with an openSUSE distribution architecture being declared a primary architecture. The primary architectures for an openSUSE distribution are the ones that are developed, tested and released together and carry the main distribution name.

While ports to other architectures are encouraged and their needs are handled best-effort, these ports need to document clearly that it is an architecture port of the respective openSUSE distribution.

Any architecture port of openSUSE that wants to be a primary architecture has to adhere to the following guidelines. This policy is defining the minimum set of rules for that. There could be also distribution specific additional policies defined.

Any nomination for a primary architecture should be brought up for discussion on the respective openSUSE distribution mailing list and also announced on the opensuse-project@ mailing list.


  • openQA: Refers to the official openSUSE openQA instance, e.g.
  • openSUSE Distribution: The binary software collections that openSUSE releases under a distribution name (e.g. Tumbleweed, Leap)

openSUSE Distribution Primary Architecture Policy

In order for an architecture to be a primary architecture, the following requirements should be met:

  • There is an active set of regular contributors that care about the distribution build and is reachable via a common mailing list for questions from packagers in case of architecture specific defects ('Architecture Team'). This Architecture Team contributes to and co-maintains the openQA test automation for this architecture. At least one member participates in the weekly openSUSE release team meeting.
  • The Tumbleweed version of the distribution is regularly publishing new snapshots (at least once a month). The openSUSE releases are published if and only if passing the defined openQA tests, which gives users the stability requirements they expect from a primary architecture.
  • The distribution milestones releases should always pass a common subset of openQA tests that make sense for this architecture. Although temporary regressions are acceptable, the distribution team should strive for the tests coverage to be continuously improved both in coverage as well as in number of passing tests.
  • The Tumbleweed Distribution is built from the openSUSE Factory set of curated sources, that are reviewed by the openSUSE review team. No permanent overlays or deviations are permitted. Temporary overlays are permitted during development in case of a severe regression on that platform (example: Newest Factory kernel-source does not boot on that architecture. In that case a temporary revert to an older, previously released source is acceptable while the regression is being resolved at highest priority.). The intention here is to decouple individual architecture release processes, however not to allow for any long-standing deviations. Primary architectures should be consistent in experience and software versions that they ship at any point in time.
  • A full Bootstrap of the distribution can be built entirely from reviewed sources starting from a set of trusted binaries. No source change is published to users on that distribution that hasn't been peer reviewed by the openSUSE Review Team.
  • The distribution maintainers are filing bugreports on for package maintainers if there are issues identified in the architecture port. The package maintainers commit to handle primary architectures with care and test-build them in the development projects before submitting changes. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution.
  • The architecture team is at all times focused on keeping every package re-buildable from sources. There should be always less than 5% of the packages failing to build from source at any point in time, and core packages for the distribution (e.g. defined as Ring-0 today) should always be successfully re-buildable and passing their build-defined test suite. A new build failure of a submission on the primary architectures is a valid reason for declining the submission.
  • The distribution build is providing tested, working set of build artifacts (Packages, Container, Installation Images, Machine images) for that architecture.
  • All primary architectures respect and follow the distribution release schedule. This means that artifacts for all primary architectures are available on the same release day. In the case of a rolling release, all artifacts for primary architectures are made available without a larger delay from each other.

Q & A

Q: Which of the current Tumbleweed ports would meet criteria for being promoted primary architecture?

A: as of 2020/06, our tests x86_64 (142 tests passing) AArch64 (81 tests passing), PowerPC (32 tests passing) and s390x (0 tests passing). That makes AArch64 the most appropriate candidate so far in this aspect.

Note: reference rather than just the bugzilla url, wiki page has lot more information. can be used as shorthand.

Q: Does a primary architecture have to care about all the packages or are packages outside a 'core' set best effort ?

There is no hard guidelines on this established in the community as of today. However common practices focus more on the "core" package set (on x86_64 this is defined by the DVD media set) than on leaf packages. Primary Architectures can define this 'core' package set differently.

Any primary architecture has to strive for a growing set of passing openQA tests that the distribution considers relevant to pass continuously.