Stable request

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

Configuration
It is preferred that testing take place on a real system, inside a chroot, or within another type of non-virtualised container. Virtualisation may be acceptable in situations where it is not possible or practical to test on real hardware.

The testing system must only have stable packages installed, with no testing packages keyworded or unmasked. It should be up-to-date, and it is recommended to have as a few packages installed as possible.

should have settings similiar to the following:

Testing
Each package in Gentoo is different and therefore requires a slightly different approach to stabilisation. Consider the following guidelines for each class of package, and use common sense when in doubt.

Libraries
A new library version may introduce incompatibles with reverse dependencies. Where there's a risk of such breakage, each stable reverse dependency must be rebuilt. Beware of reverse dependencies that only use the library conditionally (eg. ).

Kernel
Kernel packages referenced in the handbook have certain exemptions from the usual stabilisation policy, so stabilisation requests are normally only filed for the first version in a long term stable branch (subsequent versions can be stabilised at the discretion of the maintainer).

First, test all available kernel options:

If that succeeds, build with your normal configuration:

After reboot, check  for anything strange and use the system as normal, trying to get a bit of uptime.

If stabilising a special feature variant such as, try to test those features.

Toolchain
New versions of toolchain packages can often introduce major changes and widespread breakage into the tree. The purpose of a stabilisation request for a toolchain package is to test the package itself on each architecture - not to detect build failures in miscellaneous packages. It is expected that such failures are managed and resolved by the maintainer (normally through tracker bugs and tinderboxing) prior to filing a stabilisation request.

Once the normal testing is successful, rebuild  (or   if the hardware permits) and once successful observe the system in normal operation for abnormalities.

Architecture-specific notes
A number of items described in earlier sections, such as checking of reverse dependencies and miscellaneous QA checks, are architecture-neutral. At a stabilisation level, the primary responsibility for carrying out these checks rests on the first architecture to stabilise an ebuild. Subsequent architectures may assume that these checks have been completed and skip them if they wish.

amd64

 * Any developer may perform stabilisations - it is not necessary to be on the arch team
 * must be added to

arm
The ARM project supports four variants - armv4, armv5, armv6, and armv7. In addition to the normal testing, the package must be build tested on each variant. If access to each variant is not possible,  is acceptable.

x86

 * Any developer may perform stabilisations - it is not necessary to be on the arch team
 * It is acceptable to stabilise in an chroot on
 * It is generally acceptable to stabilise a package with only a build test on if it is already stable on

Acknowledgements
Most of this guide was shameless stolen from many sources, including but not limited to:
 * Agostino Sarubbo
 * Various arch teams