This article describes the procedure for moving an ebuild from testing to stable.
Checklist for a 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?
- Are there other bug reports regarding this package?
- Is the ebuild older than 30 days?
- Are its dependencies all marked stable?
- 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.
The primary purpose of the stabilization process is to integrate a testing ebuild into 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.
Everybody can request a stabilization. The maintainer (or Proxied Maintainer) will CC to the arches.
Package list- a fully qualified package per line, optionally followed by a space-delimited list of architectures to target. If no architecture list is provided, all architectures in
CCare assumed. Formerly, this field was called
Atoms to stabilizeand contained fully qualified atoms, which is also still supported.
Runtime testing required- indicates if additional runtime testing should be performed beyond build and tests passing. If undefined the arch tester should use their best judgement
|Summary||foo-libs/libbar-1.2.3 stabilization request|
|Runtime testing required||No|
|Package list||foo-libs/libbar-1.2.3 (old syntax, still supported: =foo-libs/libbar-1.2.3)|
|Summary||app-foo/bar-1.2.3 and app-foo/baz-4.5.6 stabilization request|
|CC||amd64 arm x86|
|Runtime testing required||Yes|
|app-foo/baz-4.5.6 amd64 x86|
If a large number of atoms are being stabilized at once, it might be preferred to use an attachment to list the atoms instead of the field. In that case, set the flag attachments so that
stabilization-list is set to
+. If multiple active attachments are flagged they will all be considered, so remove the flag from or mark as obsolete old attachments. If both the atoms field is completed and an attachment is flagged, only the atoms field is considered.
Periodically a bot will review stabilization requests for completeness and complain if there are invalid or missing atoms, setting a
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
If you maintain an architecture-independent package (data files, icons, pure Perl,...) then you may request that your package be stabilized on all arches at once. To do this — when you are filing the stabilization bug — please add the keyword
ALLARCHES in addition to
STABLEREQ and CC the arches that you would like to stabilize.
The arch teams, when encountering the
ALLARCHES keyword, should perform their usual set of tests on a single convenient architecture. Then, if everything works, stabilize not only the arch that was used during testing, but also all of the other arches in CC on the bug. Afterwards, the CC field can be cleared and the bug closed if appropriate.
- Package testing - An article describing how to configure a Gentoo system for testing ebuilds.
- Bugzilla/Bug report guide#Package XY should be marked stable