User-submitted Ebuilds

User-submitted ebuilds should never be blindly trusted and should always be well-tested and audited before being committed to the tree. The developer committing the user-submitted ebuild is vouching that the ebuild meets all Gentoo Linux development standards.

The user-submitted ebuild must not contain custom headers like this:

# Ebuild updated by: me <me@example.com>

Such information should be included in the git commit message instead. The use of tags such as Suggested-By: or Reported-By: in the commit message, as explained in the commit message format section, is highly encouraged. Note that ebuilds received in the form of git patches or pull requests will have the user as the commit author by default, in which case including the user information in the commit message explicitly may not be necessary.

Users should be encouraged to submit diffs to an existing ebuild if they are submitting an upgrade. Doing this will help to avoid re-introduction of previously fixed bugs into "new" ebuilds. When not working from a diff but from a complete user-submitted ebuild, the diff command should be used to see what has changed; attention should be payed for anything from the current ebuild that should appear in the new ebuild, or anything in the new ebuild that should be fixed or removed.

In general, it is preferable to have the user do the work required to get their ebuild up to par, so that they can learn from their mistakes and submit cleaner ebuilds in the future. Be sure to be thankful for any submission, even if it isn't very good. Be polite but honest — if an ebuild isn't usable, the user can be told in a way that does not insult their current ebuild-writing abilities. Remember that the user who submitted that broken ebuild may be a skilled and productive member of our project in the future — that is, if they receive the right amount of encouragement and support and continue to improve in their abilities.