Stable request

This article describes the procedure for moving an ebuild from testing to stable.

Tip
Users should request stabilization from the maintainers of a package if it is working well and has been in tree long enough. Stabilization, especially first-time instances, only occurs when a need arises or a request is made.

Warning
Users should not manually CC arch teams. Users should let the maintainer handle that in case they want to use a different version or it is not ready.

Invocation

user $pkgdev bugs -s =dev-java/bndlib-7.0.0

Checking =dev-java/bndlib-7.0.0 on 'amd64 arm64 ppc64'
Checking =dev-java/bnd-annotation-7.0.0 on 'amd64 arm64 ppc64'
Checking =dev-java/bnd-util-7.0.0 on 'amd64 arm64 ppc64'
Checking =dev-java/libg-7.0.0 on 'amd64 arm64 ppc64'
Checking =dev-java/osgi-service-log-1.3.0 on 'amd64 arm64 ppc64'
Merging =dev-java/bnd-util-7.0.0 into =dev-java/bndlib-7.0.0
Merging =dev-java/osgi-service-log-1.3.0 into =dev-java/bndlib-7.0.0, =dev-java/bnd-util-7.0.0

Checklist for a stabilization request

Important
Users only need to ensure the package works correctly for them and has ideally been in the tree for ~30 days. Developers will handle the rest. Checking more is just a nice bonus.

The requirements for stabilization can be found in the Section Keywording of the Developer Manual. Go through this checklist before opening a new stabilization request.

Live ebuilds (-9999) cannot be stabilized
See KEYWORDS for more information on stable/unstable branch
Did you test the version you want to become stable thoroughly?
Do tests pass? (FEATURES=test) (not necessary to check as a user)
Are there other bug reports regarding this package (focus on regressions)?
Is the ebuild older than 30 days (sooner for security issues or serious regressions)?
Are its dependencies all marked stable? (This can be handled in the same bug)
The stabilization requires developer time. Until we have automatic stabilization it makes sense to limit stabilization requests to ebuilds which benefit somehow from a stabilization.

Responsibility

The primary purpose of the stabilization process is to ensure an ebuild is ready for all users in the official Gentoo ebuild repository. This can involve maintaining the consistency of the dependency graph, basic compatibility checks with other packages, and smoke testing of the package itself.

Stabilization is not intended to relieve a package maintainer of their responsibility to ship a quality package - the primary responsibility of ensuring that a package is a good stable candidate remains with the person approving the stabilization request. The stabilization process does not include more than basic functionality checks unless explicitly requested.

Requesting stabilization

Everybody can request stabilization by means of a stabilization bug ticket. Please request stabilization if a package you use and enjoy is not marked stable.

Sanity check

Periodically NATTkA will review stabilization requests for completeness and complain if there are invalid or missing atoms, setting a sanity-check+ or sanity-check- flag as appropriate. This allows arch team members to filter out requests that are not known-good if they wish. A series of architecture-specific saved searches are available for convenience.

Simultaneous stabilization on all architectures

Important
Developers should add <stabilize-allarches> to metadata.xml to ensure consistency.

Maintainers of architecture-independent packages (data files, icons, pure Perl,...) may request that the package is stabilized on all arches at once. When filing the stabilization bug please add the keyword ALLARCHES in addition and CC the arches.

ALLARCHES advises the arch teams to stabilize all CCed arches, if their tests for a single arch succeeded.

External resources