public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Ulrich Müller" <ulm@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/
Date: Tue, 19 Apr 2016 10:40:59 +0000 (UTC)	[thread overview]
Message-ID: <1461062393.7ecc327a201853f40f04dbb2227a3f34a84ea7ea.ulm@gentoo> (raw)

commit:     7ecc327a201853f40f04dbb2227a3f34a84ea7ea
Author:     Göktürk Yüksek <gokturk <AT> binghamton <DOT> edu>
AuthorDate: Mon Apr  4 04:34:28 2016 +0000
Commit:     Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Tue Apr 19 10:39:53 2016 +0000
URL:        https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=7ecc327a

ebuild-maintenance: s/herd/project/ per GLEP 67 #572144

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144
Signed-off-by: Göktürk Yüksek <gokturk <AT> binghamton.edu>

 ebuild-maintenance/text.xml | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 5b2abee..a299bf2 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -281,7 +281,18 @@ which is often more convenient.
 <section>
 <title>Touching other developers ebuilds</title>
 <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> 
+<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 project 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>


             reply	other threads:[~2016-04-19 10:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 10:40 Ulrich Müller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-01-23  8:40 [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/ Ulrich Müller
2017-09-25  4:40 Göktürk Yüksek
2017-09-25  4:40 Göktürk Yüksek
2017-07-29 20:48 Göktürk Yüksek
2017-01-22 20:45 Göktürk Yüksek
2016-11-20 20:46 Göktürk Yüksek
2016-08-18  9:01 Ulrich Müller
2016-05-22  8:35 Ulrich Müller
2016-05-01  3:49 Göktürk Yüksek
2016-04-24  0:47 Göktürk Yüksek
2016-04-23 19:26 Göktürk Yüksek
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2015-05-09 15:22 Ulrich Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1461062393.7ecc327a201853f40f04dbb2227a3f34a84ea7ea.ulm@gentoo \
    --to=ulm@gentoo.org \
    --cc=gentoo-commits@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox