The policies in place are largely the same as Gentoo's, but with some special dispensations for our needs. Reading the Gentoo guidelines is necessary to understand our policies.

Licensing and trademarks

All new ebuilds in Galapagos, as well as changes to existing ebuilds, are GPLv2. This is to remain compatible with Gentoo.

When upstreaming any ebuild to Gentoo, the copyright must be assigned to the Gentoo Foundation.

Security policy

Security is job #1 at Galapagos. We take security very seriously. Gentoo has a track record of... not.

• ebuilds are to be bumped for fixed security issues and insecure ebuilds masked
• All security issues shall have a Galapagos Security Advisory (GaSA) in the same format as Gentoo's GLSA's
• Upstream are to be notified of any security issues we discover
• Insecure ebuilds masked for security issues are to be removed within 30 days, no exceptions

Abandonware policy

The Gentoo tree has a great deal of abandonware in it. It's time for much of it to go. This reduces QA burden as well as purging packages that simply bloat the tree and are of no use.

• No upstream, no keeping - if there is no active upstream for the package (defined as having a release within 2 years AND is not responsive to issues (both conditions must be met), it can't be kept
  • Accelerated removal may occur if upstream announces their demise, and no alternatives are available
  • Exceptions will be made on a case-by-case basis and the packages affected re-evaluated periodically
• Packages are to be masked for 30 days for removal to allow users to transition; any alternatives are to be mentioned
• Packages that have lagged behind for more than 3 versions and have no open bugs in Gentoo or Galapagos are ok to mask and then remove
  • The sole exception: packages in @system (or @system dependencies) may not be removed without prior discussion
• Packages obsoleted by another package are to be masked accordingly and a transition plan created by the maintainer

Shadowing of ebuilds

In the course of Galapagos development, ebuilds will become shadowed by us; that is to say, Gentoo's ebuilds will be overwritten by our modified versions, or removed. The policy is as follows:

• ebuilds added or removed by us and kept by Gentoo are to stay removed unless there is a maintainer willing to step up and it meets the abandonware/security guidelines
• ebuilds modified by us are to prefer our changes upon updates, except at maintainer discretion
• Revision bumps are mandatory for any changes to Gentoo ebuilds

Revision bumping

It is not always clear in Gentoo when to do a revision bump and is entirely left to developer opinion. Our policy strives to be objective.

ebuilds

1. Revision bumps are not necessary for build fixes, ONLY if the ebuild could never be built to begin with (for example, due to a syntax error)
2. Test suite updates and repairs do not result in a revbump unless other portions of the build must be changed
3. All other changes to the ebuild must result in a revision bump, no matter how small, even if it is just an inherit statement, EAPI bump, or a simple build fix for a new build failure (rationale: even small changes could result in new bugs)

eclasses

1. Revision bumps are not necessary for bug fixes to the eclass
2. Revision bumps are not necessary for adding or removing functionality, as long as it does not affect existing ebuilds
3. All other changes (including intrusive changes, rewriting the eclass, changing the eclass API, etc.) must result in a revision bump, OR a gradual phaseout of deprecated features in the eclass and transition to new ones; the latter is preferred in all cases