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 desribes 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 a word unless you know he does not mind or if you are part of the herd involved in maintenance (those information can be found in metadata.xml). Start with filing a bug or try 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 one and needs to be handled ASAP. Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable timeframe 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. +