© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-09-10 00:30:43 UTC
FreeBSD German Documentation Repository
Modified files:
books/developers-handbook/policies chapter.sgml
Log:
Kapitel 5 gegengelesen und korrigiert.
Gesendet von: Dennis Knorr
Revision Changes Path
1.6 +86 -83 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.5
retrieving revision 1.6
diff -u -I$FreeBSDde.*$ -r1.5 -r1.6
--- chapter.sgml 31 Aug 2007 06:13:10 -0000 1.5
+++ chapter.sgml 10 Sep 2007 00:30:43 -0000 1.6
@@ -54,22 +54,22 @@
um beigesteuerte Software handelt, er neue Versionen verfolgt
und diese bereitstellt.</para>
- <para>Änderungen an Verzeichnissen, welcher ein Maintainer
+ <para>Änderungen an Verzeichnissen, welche 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
+ Ü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>
+ Gruppe den Status eines Maintainers zu geben, so lange sie nicht
+ zustimmt, diese Pflicht auf sich zu nehmen. Andererseits muss es kein
+ einzelner Mensch sein. Eine Gruppe von Menschen ist genauso
+ in Ordnung.</para>
</sect1>
<sect1 id="policies-contributed">
@@ -95,48 +95,49 @@
<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>,
+ <emphasis>contributed</emphasis> Software. Beispiele dafür
+ sind <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>
+ um solche Software zu verwalten und alle haben Vorteile
+ wie auch Nachteile. Dabei hat sich kein Gewinner
+ herauskristallisiert</para>
- <para>Es wurde viel über diesen Umstand debattiert und so
- wurde eine Methode als die <quote>offizielle</quote> Methode
+ <para>Es wurde viel über diesen Umstand diskutiert und so
+ wurde eine Methode als die <quote>offizielle</quote> Version
gewählt, um in Zukunft diese Art der Software zu
- importieren. Ferner wird es dringend vorgeschlagen, dass
+ importieren. Ferner wird dringend geraten, 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>
+ annähert, da es signifikante Vorteile gegenüber der
+ alten Methode gibt. Dazu gehört auch die
+ Leistungsfähigkeit einfache Diffs, bezogen auf die
+ <quote>offiziellen</quote> Version, für jeden zu erzeugen,
+ auch ohne CVS-Zugang. Dies wird es deutlich vereinfachen,
+ Ä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
+ möglich ist, 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
+ 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-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>
+ nutzt, ist von kleinen und/oder kosmetischen Änderungen
+ <emphasis>sehr abzuraten</emphasis> bei Dateien, welche
+ den Herstellerzweig verfolgen. <quote>Grammatikalische oder
+ sprachliche 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
@@ -145,23 +146,25 @@
<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
- <filename>compat</filename> vor dem Import entfernt.</para>
+ Teile, welche unter FreeBSD nicht gänzlich nutzbar sind,
+ können entfernt werden. Im Fall von Tcl wurden die
+ Unterverzeichnisse <filename>mac</filename>,
+ <filename>win</filename> und <filename>compat</filename>
+ vor dem Import entfernt.</para>
- <para><filename>src/lib/libtcl</filename> enthält nur ein
+ <para><filename>src/lib/libtcl</filename> enthält ein
<filename>Makefile</filename> im
<application>bmake</application>-Stil, welches die Regeln des
Standard-Makefile <filename>bsd.lib.mk</filename> nutzt, um
die Bibliothek zu erstellen und die Dokumentation zu
installieren.</para>
- <para><filename>src/usr.bin/tclsh</filename>enthält nur ein
- <filename>Makefile</filename> im bmake-Stil, welches das
+ <para><filename>src/usr.bin/tclsh</filename>enthält ein
+ <filename>Makefile</filename> im
+ <application>bmake</application>-Stil, welches das
<command>tclsh</command>-Programm erstellt und installiert,
- ebenso die dazugehörigen Manualpages, welche die Regeln
- von <filename>bsd.prog.mk</filename> nutzen.</para>
+ ebenso die dazugehörigen Manualpages, welche die Regeln von
+ <filename>bsd.prog.mk</filename> nutzen.</para>
<para><filename>src/tools/tools/tcl_bmake</filename> enthält
einige Shellskripte, welche hilfreich sein können, wenn die
@@ -170,20 +173,19 @@
<para>Das Entscheidende ist hier das
<filename>src/contrib/tcl</filename>-Verzeichnis, welches durch
- die entsprechenden Regeln erstellt wird: Es wird unterstellt,
- dass der Quelltext im Original vorhanden ist
- (ohne RCS-Schlüsselworte und im korrekten
- CVS-Herstellerzweig) mit so wenig wie möglich
- FreeBSD-spezifischen Änderungen. Sollte es Zweifel geben,
- wie hier zu verfahren ist, ist es selbstverständlich
- zuerst nachzufragen und nicht auf gut Glück etwas zu
- probieren in der vagen Hoffnung, dass es <quote>irgendwie
- tut</quote>.
- CVS vergibt keine Fehler beim Importieren und ein hoher
- Arbeitsaufwand wäre die Folge, um diesen grossen Fehler
- wieder wettzumachen.</para>
+ die entsprechenden Regeln erstellt wird: Man nimmt an, dass der
+ Quelltext im Original vorhanden ist (ohne
+ RCS-Schlüsselworte und im korrekten CVS-Herstellerzweig)
+ mit so wenig FreeBSD-spezifischen Änderungen wie
+ möglich. Sollte es Zweifel geben, wie hier zu verfahren
+ ist, ist es selbstverständlich zuerst nachzufragen und
+ nicht auf gut Glück etwas zu probieren in der vagen
+ Hoffnung, dass es <quote>irgendwie tut</quote>. CVS vergibt
+ keine Fehler beim Importieren und ein hoher Arbeitsaufwand
+ wäre die Folge, um diesen grossen Fehler wieder
+ wettzumachen.</para>
- <para>Durch die Eingangs schon erwähnten Einschränkungen
+ <para>Durch die eingangs schon erwähnten Einschränkungen
durch das Design beim CVS-Herstellerzweig, ist es erforderlich,
dass <quote>offizielle</quote> Fehlerbehebungen vom Hersteller
bei den Originalquellen der Distribution einfliessen und als
@@ -198,20 +200,20 @@
Kompatibilität mit anderen Architekturen und Umgebungen
wie FreeBSD gedacht sind, ist es zulässig diese Teile zu
löschen, wenn sie für FreeBSD nicht von Interesse
- sind, da dadurch Speicherplatz gespart wird. Dateien welche
- ein Copyright enthalten und eine Art von Release-Informationen
- zu den vorhandenen Dateien, sollten
- <emphasis>nicht</emphasis> gelöscht werden.</para>
+ sind, da dadurch Speicherplatz gespart wird. Dateien, welche ein
+ Copyright und Release-artige Informationen zu den vorhandenen
+ Dateien enthalten, sollten <emphasis>nicht</emphasis>
+ gelöscht werden.</para>
<para>Falls es einfacher erscheint können die
- <command>bmake</command>-<filename>Makefile</filename>s
- vom Verzeichnisbaum durch einige Dienstprogramme
- automatisch erstellt werden, was es hoffentlich
- sogar noch einfacher macht auf eine Version zu aktualisieren.
- Ist dies geschehen, so stellen Sie bitte sicher diese Werkzeuge
- in das Verzeichnis <filename>src/tools</filename> mit dem Port
- an sich einzuchecken, so dass es für zukünftige
----------------------------------------------
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 Mon 10 Sep 2007 - 02:32:11 CEST