commit e6ebf193852f92aa1dfec162f1bcdc34e933eda1 Author: hasufell Date: Sat Dec 1 00:04:51 2012 +0100 add ebuild comitting guide section diff --git a/ebuild-committing-guide/cvs-tutorial/text.xml b/ebuild-committing-guide/cvs-tutorial/text.xml new file mode 100644 index 0000000..a2bd612 --- /dev/null +++ b/ebuild-committing-guide/cvs-tutorial/text.xml @@ -0,0 +1,14 @@ + + + +CVS Tutorial + + +

+TODO: write something here. +

+ + + + + diff --git a/ebuild-committing-guide/ebuild-policy/text.xml b/ebuild-committing-guide/ebuild-policy/text.xml new file mode 100644 index 0000000..44ce9aa --- /dev/null +++ b/ebuild-committing-guide/ebuild-policy/text.xml @@ -0,0 +1,14 @@ + + + +Ebuild policy + + +

+TODO: write something here. +

+ + + + + diff --git a/ebuild-committing-guide/text.xml b/ebuild-committing-guide/text.xml new file mode 100644 index 0000000..db8e982 --- /dev/null +++ b/ebuild-committing-guide/text.xml @@ -0,0 +1,23 @@ + + + +Ebuild Committing Guide + + +

+This section describes how to commit an ebuild. It covers the basics of handling CVS commits and describes some ebuild and tree policies. +

+ + +
+Contents + + + +
+ + + + + + diff --git a/ebuild-committing-guide/tree-policy/text.xml b/ebuild-committing-guide/tree-policy/text.xml new file mode 100644 index 0000000..1c56a00 --- /dev/null +++ b/ebuild-committing-guide/tree-policy/text.xml @@ -0,0 +1,23 @@ + + + +Tree and Etiquette policy + + +

+This section outlines the etiquette policy for Gentoo developers and describes common sense when dealing with problems in the tree. +

+
+Changing/Fixing other developers ebuilds + +

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.

+ 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. + +
+ + + + + + + diff --git a/text.xml b/text.xml index 88016b0..137a99f 100644 --- a/text.xml +++ b/text.xml @@ -50,6 +50,7 @@ section lists specific contributions to this manual. +