Gentoo Archives: gentoo-dev

From: "Göktürk Yüksek" <gokturk@××××××××××.edu>
To: devmanual@g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] [PATCH v1 2/3] ebuild-maintenance: s/herd/project/ per GLEP 67 #572144
Date: Mon, 04 Apr 2016 04:35:08
Message-Id: 1459744469-21780-3-git-send-email-gokturk@binghamton.edu
In Reply to: [gentoo-dev] [PATCH v1 0/3] devmanual: update the docs per GLEP 67 by "Göktürk Yüksek"
1 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144
2 Signed-off-by: Göktürk Yüksek <gokturk@××××××××××.edu>
3 ---
4 ebuild-maintenance/text.xml | 13 ++++++++++++-
5 1 file changed, 12 insertions(+), 1 deletion(-)
6
7 diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
8 index 5b2abee..a299bf2 100644
9 --- a/ebuild-maintenance/text.xml
10 +++ b/ebuild-maintenance/text.xml
11 @@ -281,7 +281,18 @@ which is often more convenient.
12 <section>
13 <title>Touching other developers ebuilds</title>
14 <body>
15 -<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>
16 +<p>
17 +Usually you don't just change other developers ebuilds without
18 +permission unless you know that developer does not mind or if you are
19 +part of the project involved in maintenance (this information can
20 +typically be found in metadata.xml). Start with filing a bug or trying
21 +to catch them on IRC or via email. Sometimes you cannot reach them, or
22 +there is no response to your bug. It's a good idea to consult other
23 +developers on how to handle the situation, especially if it's a
24 +critical issue that needs to be handled ASAP. Otherwise a soft limit
25 +of 2 to 4 weeks depending on the severity of the bug is an acceptable
26 +time frame before you go ahead and fix it yourself.
27 +</p>
28 <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>
29
30 <p>
31 --
32 2.7.3