diff options
| author |   Ulrich Müller <ulm@gentoo.org> | 2015-05-03 19:17:29 +0200 |
|---|---|---|
| committer | Ulrich Müller <ulm@gentoo.org> | 2015-05-07 00:06:49 +0200 |
| commit | 75f4240dbc7b4710247e7b3ed3bb6e564cfbad60 (patch) | |
| tree | 5b70816e58db242ab96530911b84c8252b8e9e8a | |
| parent | Merge sentence about 9999 naming policy from Developer Handbook. (diff) | |
| download | devmanual-75f4240dbc7b4710247e7b3ed3bb6e564cfbad60.tar.gz devmanual-75f4240dbc7b4710247e7b3ed3bb6e564cfbad60.tar.bz2 devmanual-75f4240dbc7b4710247e7b3ed3bb6e564cfbad60.zip | |
Merge section about user-submitted ebuilds from Developer Handbook.
This is taken from proj/en/devrel/handbook/hb-policy-ebuild.xml,
section "Ebuild policy", subsection "User-submitted ebuilds".
Permission to reuse the CC-BY-SA-1.0 work under CC-BY-SA-2.0
(or any later version) obtained from author plasmaroo per e-mail
on 2015-04-16.
| -rw-r--r-- | ebuild-writing/text.xml | 1 | ||||
| -rw-r--r-- | ebuild-writing/user-submitted/text.xml | 53 |
2 files changed, 54 insertions, 0 deletions
diff --git a/ebuild-writing/text.xml b/ebuild-writing/text.xml index 2f55b47..9420045 100644 --- a/ebuild-writing/text.xml +++ b/ebuild-writing/text.xml @@ -29,5 +29,6 @@ with some general notes and extended examples. <include href="using-eclasses/"/> <include href="functions/"/> <include href="misc-files/"/> +<include href="user-submitted/"/> <include href="common-mistakes/"/> </guide> diff --git a/ebuild-writing/user-submitted/text.xml b/ebuild-writing/user-submitted/text.xml new file mode 100644 index 0000000..ef80c0d --- /dev/null +++ b/ebuild-writing/user-submitted/text.xml @@ -0,0 +1,53 @@ +<?xml version="1.0"?> +<guide self="ebuild-writing/user-submitted/"> +<chapter> +<title>User-submitted Ebuilds</title> + +<body> + +<p> +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. +</p> + +<p> +The user-submitted ebuild must not contain custom headers like this: +</p> + +<pre caption="A custom header that should be transferred to the ChangeLog"> +# Ebuild updated by: me <me@example.com> +</pre> + +<p> +Such information should be added to the <c>ChangeLog</c> instead. +The first <c>ChangeLog</c> entry should always credit the user who +submitted the ebuild, with their full name and e-mail address. +</p> + +<p> +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 <c>diff</c> 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. +</p> + +<p> +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 <d/> 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 <d/> that is, if they receive the right amount +of encouragement and support and continue to improve in their abilities. +</p> + +</body> +</chapter> +</guide> |