Project:Quality Assurance/Policies

Tree-Related Policies

General Notes

In the case that a feature of an ebuild violates policy but the QA team has reviewed the situation and given an exception, this should be noted in a comment in the ebuild

USE-Controlled Optional RDEPENDs

We do not have a specific recommendation for how to notify the user of optional dependencies (elogs and readme.gentoo are both viable options), but USE-controlled optional RDEPs are not acceptable except under very specific circumstances, such as a package being nonfunctional unless at least one of a set of RDEPs is installed. If in doubt, ask the QA team to review the situation.

multislot/USE-dependent SLOT

USE=multislot (and other USE-dependent SLOT values) do not belong in the tree. They may be used in overlays, and we consider it acceptable to have eclasses which support multislot as long as it is not used in-tree (so that maintainers do not need to maintain two near-identical versions of the same eclass).

Versioned USE flags

We recommend that in future situations like this (a package can optionally depend on different versions of a library), we recommend the use of versioned USE flags. It should be discussed with the QA team before introduction.

Dropping Stable KEYWORDs

The maintainer may drop stable keyword or last stable version, if arch team does not respond within 90 days; if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version. The developer should follow the policy for removing a package, except for last rites emails, when removing the last stable version or stable keyword from a package.

Games

The /usr/games and /etc/games directories are deprecated. Games packages should not install any files there, but follow the normal guidelines for install locations instead. Two exceptions are made:

Games packages can install files in /usr/share/games (instead of /usr/share) if that is the location used by upstream.
Shared high-score or game state files can be placed in /var/games or a subdirectory of it.

Reference: Council meeting summary 2015-12-13.

Directories ~~/usr/games, /usr/games/bin, /usr/games/lib*,~~ /usr/share/games, /var/games, ~~and /etc/games~~ which are shared by multiple packages must have owner root:root and permissions 755 (i.e., the default).

Games that need privileged access to shared high-score or game state files can be installed setgid (mode g+s or 2755). Group "gamestat" with gid 36 (but not the "games" group) should be used for them. The files for state/scores should then be created in /var/games or a subdirectory of it and have appropriate owner and permissions (root:gamestat, mode g+w).

Discussion reference: QA team meeting 2015-02-18.

Ebuild code must be wholly contained in ebuild and eclass files

The ebuild code must be wholly contained in files that are defined by the PMS, which as of 2017-03-24 are .ebuild and .eclass files. It is explicitly forbidden to split the ebuild code into additional files that are loaded via source, eval or any other possible method.

Discussion + rationale reference: bug #612630

QA Team-Related Policies

Policymaking Workflow

When a person brings us problem, we look into the problem and discuss it at meeting. If there is no policy on problem, we make policy; if the policy or documentation is unclear, we update it. If the policy is actively being ignored we politely ask the person to stop. It is more reactive than proactive, this does not preclude emergency action on our part. This will give the team the time to work out basic rules and workflows, we might do more proactive tasks later one, if there is any need for them. However, if we think somebody is breaking the tree, we can ask them to stop and/or undo what they did pending a review at a QA meeting.

Communicating New Policy

Emailing gentoo-dev@ and gentoo-dev-announce@ and updating this wiki page are the minimum for announcing new policies. Blog posts are also encouraged.

Communication When Making Fixes

We fix and send a friendly reminder to the maintainer(s) for trivial fixes; open bug, wait 2 weeks, make the change for larger but non-critical fixes; make the change and send a notification for critical fixes.

Action Policy and Internal Dispute Resolution

QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. Any action which is disputed can be settled by a team vote, and the result of that vote will be the final decision.