aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorUlrich Müller <ulm@gentoo.org>2015-05-03 20:07:39 +0200
committerUlrich Müller <ulm@gentoo.org>2015-05-07 00:06:49 +0200
commit960ae7a0f9ef60d3afb7e47ed27e4707ed284756 (patch)
tree230c2f89ee758ecbcd4ad11eab02351fc2fe2c01 /ebuild-maintenance
parentMerge package.mask policy from Developer Handbook. (diff)
downloaddevmanual-960ae7a0f9ef60d3afb7e47ed27e4707ed284756.tar.gz
devmanual-960ae7a0f9ef60d3afb7e47ed27e4707ed284756.tar.bz2
devmanual-960ae7a0f9ef60d3afb7e47ed27e4707ed284756.zip
Merge ebuild etiquette policy from Developer Handbook.
This is taken from proj/en/devrel/handbook/hb-policy-etiquette.xml, section "Tips", subsection "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.
Diffstat (limited to 'ebuild-maintenance')
-rw-r--r--ebuild-maintenance/text.xml9
1 files changed, 9 insertions, 0 deletions
diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 7325b66..ac68dcd 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -180,6 +180,15 @@ which is often more convenient.
<body>
<p>Usually you don't just change other developers ebuilds without permission unless you know that developer does not mind or if you are part of the herd involved in maintenance (this information can typically be found in metadata.xml). Start with filing a bug or trying to catch them on IRC or via email. Sometimes you cannot reach them, or there is no response to your bug. It's a good idea to consult other developers on how to handle the situation, especially if it's a critical issue that needs to be handled ASAP. Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself.</p>
<important> Common sense dictates to us that toolchain/base-system/core packages and eclasses or anything else which is delicate (e.g. glibc) or widely used (e.g. gtk+) should usually be left to those maintainers. If in doubt, don't touch it.</important>
+
+<p>
+Respect developers' coding preferences. Unnecessarily changing the
+syntax of an ebuild can cause complications for others. Syntax changes
+should only be done if there is a real benefit, such as faster
+compilation, improved information for the end user, or compliance with
+Gentoo policies.
+</p>
+
</body>
</section>