© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-08-29 02:43:33 UTC
FreeBSD ports repository
Modified files:
books/developers-handbook/policies chapter.sgml
Log:
Korrekturlesung vom Kapiel 5.
( es folgt eine 2.!)
Gesendet von: ds@
Revision Changes Path
1.3 +231 -215 de-docproj/books/developers-handbook/policies/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/developers-handbook/policies/chapter.sgml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -I$FreeBSDde.*$ -r1.2 -r1.3
--- chapter.sgml 25 Aug 2007 03:19:35 -0000 1.2
+++ chapter.sgml 29 Aug 2007 02:43:33 -0000 1.3
@@ -12,7 +12,7 @@
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
- <contrib>Beigesteuert von</contrib>
+ <contrib>Beigesteuert von </contrib>
</author>
</authorgroup>
<!-- June 1996 -->
@@ -20,44 +20,45 @@
<title>Vorgaben und Richtlinien für das Quelltextverzeichnis</title>
- <para>Dieses Kapitel dokumentiert verschiedene Vorgaben und
- Richtlinien für das FreeBSD Quelltextverzeichnis.</para>
+ <para>Dieses Kapitel dokumentiert verschiedene Vorgaben und
+ Richtlinien für das FreeBSD-Quelltextverzeichnis.</para>
<sect1 id="policies-maintainer">
<title><makevar>MAINTAINER</makevar> eines Makefiles</title>
<indexterm><primary>Ports Maintainer</primary></indexterm>
- <para>Wenn ein bestimmter Bereich der FreeBSD Distribution von
- einer Person, oder Gruppe, gepflegt wird, kann dies durch
- hinzufügen der Zeile
+ <para>Wenn ein bestimmter Bereich der FreeBSD-Distribution von
+ einer Person oder Gruppe gepflegt wird, kann dies durch
+ Hinzufügen der Zeile
<programlisting>MAINTAINER= email-addresses</programlisting>
- im<filename>Makefile</filename>der Welt mitgeteilt werden.</para>
+ im <filename>Makefile</filename> der Öffentlichkeit
+ mitgeteilt werden.</para>
<para>Dies bedeutet folgendes:</para>
- <para>Der Maintainer ist verantwortlich für diesen Code code. Dies
- bedeutet, dass er einerseits für die Behebung von Fehlern und dem
- beantworten von Problemberichten für diesen Code die
- Verantwortung trägt, andererseits, so es sich um
- beigesteuerte Software handelt, er neue Versionen verfolgt und
+ <para>Der Maintainer ist verantwortlich für diesen Code. Dies
+ bedeutet, dass er einerseits für die Behebung von Fehlern
+ und das Beantworten von Problemberichten für diesen Code
+ die Verantwortung trägt, andererseits, falls es sich um
+ beigesteuerte Software handelt, er neue Versionen verfolgt und
diese bereitstellt.</para>
- <para>Änderungen an Verzeichnissen welcher ein Maintainer
- definiert hat, sollten an den Maintainer, für eine
- Üperprüfung gesendet werden, bevor diese committed
- werden. Nur wenn der Maintainer in einer inakzeptablen Zeitspanne,
- auf mehrere E-Mails, nicht antwortet, können die
- Änderungen durch den commit, auch ohne Üperprüfung
- des Maintainers, vollzogen werden. Dennoch wird vorgeschlagen,
- dass die Änderungen, wenn möglich, durch jemand anderen
- Überprüpft werden.</para>
-
- <para>Es ist nicht akzeptabel einer Person, oder Gruppe, den Status
- eines Maintainers zu geben, so lange dieser Pflicht nicht
- zugestimmt wird. Auf der anderen Seite muss es kein Committer sein
- und so kann es leicht eine Gruppe von Leuten sein.</para>
+ <para>Änderungen an Verzeichnissen, welcher ein Maintainer
+ definiert hat, sollten an den Maintainer für eine
+ Überprüfung gesendet werden, bevor diese committed
+ werden. Nur wenn der Maintainer in einer inakzeptablen Zeitspanne
+ auf mehrere E-Mails nicht antwortet, können die
+ Änderungen durch den Commit, auch ohne Überprüfung
+ des Maintainers, vollzogen werden. Dennoch wird vorgeschlagen,
+ dass die Änderungen, falls möglich, durch jemand anderen
+ überprüft werden.</para>
+
+ <para>Es ist natürlich nicht akzeptabel einer Person oder Gruppe
+ den Status eines Maintainers zu geben, so lange dieser Pflicht nicht
+ zugestimmt wurde. Andererseits muss es kein Committer und auch eine
+ eine Gruppe von Menschen ist selbstverständlich legitim.</para>
</sect1>
<sect1 id="policies-contributed">
@@ -66,7 +67,7 @@
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
- <contrib>Beigesteuert von</contrib>
+ <contrib>Beigesteuert von </contrib>
</author>
<author>
<firstname>David</firstname>
@@ -80,147 +81,156 @@
<indexterm><primary>Beigesteuerte Software</primary></indexterm>
- <para>Einige Teile der FreeBSD Distribution enthalten Software
- welche aktiv ausserhalb des FreeBSD Projects gepflegt wird.
- Aus historischen Gründen nennen wir dies
+ <para>Einige Teile der FreeBSD-Distribution enthalten Software,
+ welche aktiv ausserhalb des FreeBSD-Projektes gepflegt wird.
+ Aus historischen Gründen nennen wir dies
<emphasis>contributed</emphasis> Software. Beispiele dazu sind
- <application>sendmail</application>, <application>gcc</application>
- und <application>patch</application>.</para>
+ <application>sendmail</application>,
+ <application>gcc</application> und
+ <application>patch</application>.</para>
- <para>Über die Jahre wurden verschiedenen Methoden genutzt um
- diese Art der Software zu handhaben, und alle haben Vorteile wie
- auch Nachteile. So gibt es keinen klaren Gewinner.</para>
-
- <para>Es wurde viel über diesen Umstand debattiert, und so
- wurde eine Methode als die <quote>offizielle</quote> Methode
- gewählt um in Zukunft diese Art der Software zu importieren.
- Ferner wird es dringend vorgeschlagen, das existierende
- beigesteuerte Software sich diesem Modell nähern, da es
- signifikante Vorteile gegenüber der alten Methode gibt.
- Beispielsweise die Leistungsfähigkeit einfach diffs von der
- <quote>offiziellen</quote> Version zu beziehen, und das für
- jedermann, (auch ohne CVS Zugang). Dies wird es deutlich einfacher
- machen Änderungen an die Hauptentwickler zurüfliessen zu
- lassen.</para>
-
- <para>Letztendlich kommt es auf die Leute an die die Arbeit machen.
- Wenn die Nutzung dieses Modells teilweise nicht Möglich ist,
- so k¨nnen Ausnahmen von diesen Regeln gewährt werden,
- diese müssen aber durch das Core Team genehmigt, und mit
- Übereinstimmung der anderen Developer, werden. Das
- Vermögen dieses Paket auch in Zukunft pflegen zu können
- ist eine der Schlüsselfragen bei dieser Entscheidung.</para>
+ <para>Über die Jahre wurden verschiedenen Methoden genutzt,
+ um diese Art der Software zu handhaben, und alle haben Vorteile
+ wie auch Nachteile. So gibt es keinen klaren Gewinner.</para>
+
+ <para>Es wurde viel über diesen Umstand debattiert und so
+ wurde eine Methode als die <quote>offizielle</quote> Methode
+ gewählt, um in Zukunft diese Art der Software zu
+ importieren. Ferner wird es dringend vorgeschlagen, dass
+ existierende, beigesteuerte Software sich diesem Modell
+ nähert, da es signifikante Vorteile gegenüber der
+ alten Methode gibt. Beispielsweise die Leistungsfähigkeit
+ einfach Diffs von der <quote>offiziellen</quote> Version zu
+ beziehen und das für jedermann (auch ohne CVS-Zugang).
+ Dies wird es deutlich einfacher machen Änderungen an die
+ Hauptentwickler zurüfliessen zu lassen.</para>
+
+ <para>Letztendlich kommt es auf die Menschen an, welche die Arbeit
+ leisten. Wenn die Nutzung dieses Modells teilweise nicht
+ möglich ist, so k¨nnen Ausnahmen von diesen Regeln
+ gewährt werden, diese müssen aber durch das Core Team
+ und mit Übereinstimmung der anderen Developer genehmigt
+ werden. Die Fähigkeit dieses Paket auch in Zukunft pflegen
+ zu können ist eine der Schlüsselfragen bei dieser
+ Entscheidung.</para>
<note>
- <para>Durch einige bedauernswerte Einschränkungen beim
- Design des RCS Dateiformats und wie CVS vendor branches nutzt,
- sind kleine und/oder kosmetische Änderungen
- <emphasis>sehr entmutigend</emphasis> bei Dateien die die
- Hersteller branche verfolgen. <quote>Sprechende Fehlerbehebungen</quote>
- sind explizit unter der <quote>kosmetischen</quote> Kategorie
- vorhanden und sollten bei Dateien mit einer 1.1.x.x Revision
- verhindert werden. Das Repository kann sich durch Änderungen
- an einzelnen Zeichen dramatisch aufblähen.</para>
+ <para>Durch einige bedauernswerte Einschränkungen beim
+ Design des RCS-Dateiformates und wie CVS Vendor Branches
+ nutzt, sind kleine und/oder kosmetische Änderungen
+ <emphasis>sehr entmutigend</emphasis> bei Dateien, welche
+ den Herstellerzweig verfolgen.
+ <quote>Sprechende Fehlerbehebungen</quote>
+ sind explizit unter der <quote>kosmetischen</quote>-Kategorie
+ vorhanden und sollten bei Dateien mit einer 1.1.x.x-Revision
+ verhindert werden. Das Repository kann sich durch
+ Änderungen an einzelnen Zeichen dramatisch
+ aufblähen.</para>
</note>
- <para>Die eingebettete <application>Tcl</application>
- Programmiersprache soll als Beispiel dienen wie dieses Modell
- funktioniert:</para>
-
- <para><filename>src/contrib/tcl</filename>enthält den
- Quelltext wie vom Maintainer dieses Paketes bereitgestellt. Teile
- welche unter FreeBSD nicht nutzbar sind, können entfernt
- werden. Im Fall von Tcl wurden die Unterverzeichnisse
- <filename>mac</filename>, <filename>win</filename> und
+ <para>Die eingebettete
+ <application>Tcl</application>-Programmiersprache soll als
+ Beispiel dienen, wie dieses Modell funktioniert:</para>
+
+ <para><filename>src/contrib/tcl</filename> enthält den
+ Quelltext wie vom Maintainer dieses Paketes bereitgestellt.
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Wed 29 Aug 2007 - 04:44:55 CEST