Project:Quality Assurance/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).

gtk/gtk2/gtk 3 USE flag situation
We mandate that gtk move to versioned USE flags. For simplicity of migration, we will allow USE=gtk to mean "depend on gtk2," since there are only a few USE=gtk2 remaining in tree. USE=gtk3 will mean "depend on gtk3." Future USE flags should follow the same pattern, with gtk4 meaning "depend on gtk4," etc. USE=gtk may not be used to mean "depend on some version of gtk."

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.

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.