diff options
| author |   Michał Górny <mgorny@gentoo.org> | 2019-09-09 09:17:46 +0200 |
|---|---|---|
| committer |   Göktürk Yüksek <gokturk@gentoo.org> | 2019-10-16 14:49:09 -0400 |
| commit | ddeb8e005a8216011b00b7cd4dcc47bb33150015 (patch) | |
| tree | b0a712ea5fb15959ea7f955a57de61f7aaf4ed0e /ebuild-maintenance | |
| parent | general-concepts/package-maintainers: Describe maintainers (diff) | |
| download | devmanual-ddeb8e005a8216011b00b7cd4dcc47bb33150015.tar.gz devmanual-ddeb8e005a8216011b00b7cd4dcc47bb33150015.tar.bz2 devmanual-ddeb8e005a8216011b00b7cd4dcc47bb33150015.zip | |
ebuild-maintenance/maintenance-tasks: "Touching other..." moved
The "Touching other developers ebuilds" section has been effectively
moved to "Package Maintainers". Remove the duplicate.
Closes: https://github.com/gentoo/devmanual.gentoo.org/pull/104
Acked-by: Michael Orlitzky <mjo@gentoo.org>
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Göktürk Yüksek <gokturk@gentoo.org>
Diffstat (limited to 'ebuild-maintenance')
| -rw-r--r-- | ebuild-maintenance/maintenance-tasks/text.xml | 33 |
1 files changed, 0 insertions, 33 deletions
diff --git a/ebuild-maintenance/maintenance-tasks/text.xml b/ebuild-maintenance/maintenance-tasks/text.xml index 06634b8..7e73937 100644 --- a/ebuild-maintenance/maintenance-tasks/text.xml +++ b/ebuild-maintenance/maintenance-tasks/text.xml @@ -137,39 +137,6 @@ which is often more convenient. </section> <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 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> -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> - -<section> <title>Stabilizing ebuilds</title> <body> |