debian-faq/de/ diffs: choosing.sgml

08/08/2008 - 11:20 von Martin Horoba | Report spam

Hallo Liste.

"Korrekturlesung";
wenige Rechtschreibfehler gefunden. Ganze Sàtze oder allgemeine Erklàrungen
habe ich nicht geàndert. (Hàtten auch nicht verstàndlicher geklungen.)

Gruß,
Martin

name="MH_choosing.sgml_diff"
filename="MH_choosing.sgml_diff"

Index: choosing.sgml
=
choosing.sgml (Revision 5332)
+++ choosing.sgml (Arbeitskopie)
@@ -13,7 +13,7 @@
<p>Um mehr Informationen über die verfügbaren Distributionen zu erhalten,
lesen Sie bitte <ref id="dists">.

-<sect>Welche Debian-Distribution (stable/testing/unstable) is geeignet für
+<sect>Welche Debian-Distribution (stable/testing/unstable) ist geeignet für
mich?

<p>Die Antwort darauf ist ein wenig kompliziert. Sie hàngt sehr davon ab, was
@@ -174,7 +174,7 @@
<p>Wenn solche Dinge passieren, sagt man von einer Distribution, dass sie
(zumindest in Bezug auf dieses eine Paket) kaputt ist.</p>

-<sect1>Wie kann es sein, das testing monatelang kaputt ist? Würden die in
+<sect1>Wie kann es sein, dass testing monatelang kaputt ist? Würden die in
unstable eingepflegten Fehlerkorrekturen nicht direkt in testing einfließen?

<p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution unstable
@@ -202,9 +202,9 @@
<item>Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein
neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu
XYZ-3.7.
- <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
- einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
- das BTS.
+ <item>Nun entdeckt am 25. Juni jemand der testing oder unstable
+ benutzt, einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet
+ diesen an an das BTS.
<item>Der Betreuer von XYZ behebt den Fehler und làdt ein neues Paket
nach unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue
@@ -216,7 +216,7 @@
daraufhin testing am 10. Juli erreichen.
<item>Aber schon am 5. Juli entdeckt wieder jemand einen
veröffentlichungskritischen Fehler in XYZ-3.8.
- <item>Nehmen wir an, der Betreuen löst das Problem und làdt die neue
+ <item>Nehmen wir an, der Betreuer löst das Problem und làdt die neue
Version von XYZ nach fünf Tagen hoch.
<item>Also ist am 10. Juli XYZ-3.7 in testing und XYZ-3.9 in unstable.
<item>Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20.
@@ -241,7 +241,7 @@
vorziehen, ist der, dass es nur sehr wenig Verwaltungsaufwand erfordert. Diese
Leute wollen ein System, das einfach nur funktioniert. Im allgemeinen kann man
sagen, dass stable nur sehr wenig Wartung bedarf, wàhrend testing und unstable
-nach fortwàhrender Pflege durch den Systemwerwalter verlangen. Wenn Sie stable
+nach fortwàhrender Pflege durch den Systemverwalter verlangen. Wenn Sie stable
verwenden, müssen Sie lediglich darauf achten, mit den Sicherheitsupdates
Schritt zu halten. Wenn Sie testing oder unstable verwenden, ist es klug, ein
Auge auf neu entdeckte Fehler, Fehlerberichtigungen und neue Fàhigkeiten in
@@ -272,24 +272,24 @@
Veröffentlichung gemacht wurde, oder nicht.
<item>Pakete wandern fortwàhrend von sid nach testing (beispielsweise
&testingreleasename;). Aber Pakete in stable (beispielsweise &releasename;)
- bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
- <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
- weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
+ bleiben immer die selben, außer im Falle von Sicherheitsupdates.
+ <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
+ weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
von unstable nach testing mehr, es sei denn, um veröffentlichungskritische
(RC) Fehler zu beheben.
- <item>Nachdem testing eingefroren wurde, müssen alle neu eingeführten
+ <item>Nachdem testing eingefroren wurde, müssen alle neu eingeführten
Fehlerkorrekturen hàndisch durch die Mitglieder des Veröffentlichungs-Teams
überprüft werden. Das soll sicherstellen, dass sich keine ernsthaften Fehler
in die eingefrorene testing-Veröffentlichung mehr einschleichen können.
<item>Die RC-Fehler im eingefrorenen testing werden auf Null reduziert.
- <item>Das eingefrorene testing wird ohne RC-Fehler als neue stabile
+ <item>Das eingefrorene testing wird ohne RC-Fehler als neue stabile
Veröffentlichung herausgegeben. In unserem Beispiel würde diese neue
Veröffentlichung &testingreleasename; genannt werden.
<item>Nun ist oldstable = &releasename;, stable = &testingreleasename;. Zu
diesem Zeitpunkt entsprechen sich der Inhalt von stable und eingefrorenem
testing.
- <item>Ein neues testing wird aus dem derzeitigen stable abgeleitet.
- <item>Pakete beginnen wieder aus sid nach testing herunterzukommen und die
+ <item>Ein neues testing wird aus dem derzeitigen stable abgeleitet.
+ <item>Pakete beginnen wieder aus sid nach testing herunterzukommen und die
Debian-Gemeinschaft beginnt auf die nàchste Veröffentlichung hinzuarbeiten.
</list>

@@ -357,12 +357,12 @@
Veröffentlichungshinweise enthalten möglicherweise Informationen über die Art,
wie Sie das Upgrade vornehmen sollten.

-<p>Dennoch können Sie nachdem sich die obigen Verànderungen vorgenommen haben,
+<p>Dennoch können Sie, nachdem Sie die obigen Verànderungen vorgenommen haben,
<prgn>aptitude update</prgn> laufen lassen und dann die Pakete installieren,
die Sie haben möchten. Beachten Sie, dass das Installieren eines Pakets aus
einer anderen Distribution möglicherweise automatisch gleich Ihr halbes System
einem Upgrade unterzieht. Wenn Sie einzelne Pakete installieren, haben Sie zum
-Schluß ein System, auf denen eine Mischung verschiedener Distributionen làuft.
+Schluss ein System, auf denen eine Mischung verschiedener Distributionen làuft.

<p>In bestimmten Situationen ist es daher wahrscheinlich das Beste, ein volles
Upgrade auf die neue Distribution zu machen, indem man <prgn>apt-get
@@ -376,8 +376,8 @@
laufen?

<p>Das hàngt von den Eintràgen in der Datei <file>/etc/apt/sources.list</file>
-ab. Wenn Sie gegenwàrtig testing mitverfolgen, sollt diese Eintràge in etwa so
-aussehen:
+ab. Wenn Sie gegenwàrtig testing mitverfolgen, sollten diese Eintràge in etwa
+so aussehen:

<example>
deb http://ftp.us.debian.org/debian/ testing main
@@ -476,7 +476,7 @@
der Paketwerkzeuge zu machen, da Sie am Ende möglicherweise mit einem
unbrauchbaren System dastehen.

-<p>Wenn sich all Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
+<p>Wenn sich alle Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
einer gesonderten Partition befinden, ist der Umstieg auf Debian ziemlich
einfach. Sie müssen das Installationssystem lediglich anweisen, diese
Partition bei der Neuinstallation einzubinden (aber nicht zu formatieren).



To UNSUBSCRIBE, email to debian-l10n-german-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Lesen sie die antworten

#1 Jens Seidel
08/08/2008 - 13:10 | Warnen spam
Hallo Martin,

On Fri, Aug 08, 2008 at 10:16:12AM +0200, Martin Horoba wrote:
"Korrekturlesung";
wenige Rechtschreibfehler gefunden. Ganze Sàtze oder allgemeine Erklàrungen
habe ich nicht geàndert. (Hàtten auch nicht verstàndlicher geklungen.)



der Patch sieht soweit gut aus, bis ich Folgendes fand:

Index: choosing.sgml
> choosing.sgml (Revision 5332)
+++ choosing.sgml (Arbeitskopie)
@@ -13,7 +13,7 @@

@@ -202,9 +202,9 @@
<item>Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein
neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu
XYZ-3.7.
- <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
- einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
- das BTS.
+ <item>Nun entdeckt am 25. Juni jemand der testing oder unstable
+ benutzt, einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet
+ diesen an an das BTS.



Bitte versuche andere Zeilenumbrüche zu vermeiden. Soweit ich sehe, hast
du nach "benutzt" ein Komma eingefügt und keine weiteren Änderungen
beabsichtigt (obwohl du ein "an an" drin hast).

Hàttest du die Zeilenumbrüche nicht geàndert, so hàttest du deinen
Fehler auch sofort entdeckt, da man dann nur

- <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
+ <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt,

erwarten würde.

Veröffentlichung gemacht wurde, oder nicht.
<item>Pakete wandern fortwàhrend von sid nach testing (beispielsweise
&testingreleasename;). Aber Pakete in stable (beispielsweise &releasename;)
- bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
- <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
- weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
+ bleiben immer die selben, außer im Falle von Sicherheitsupdates.
+ <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
+ weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete



Solche Änderungen in der Einrückung sind eigentlich auch unnötig und
machen das Korrekturlesen nur komplizierter. Könntest du solche Dinge
nach Möglichkeit in einem separaten Patch schicken, da sowas ja nicht
gelesen werden muss (diff mit Option -b würde ich zum Überprüfen eines
solches Patches wàhlen, da dies keine Ausgabe haben solle)?

Der Patch sieht abgesehen davon sehr gut aus. Sende mir bitte noch
mal zwei kleine Patches (einer nur mit Rechtschreibfehlern, der andere
nur mit Änderungen der Einrückungen), beide ohne andere Zeilenumbrüche.

Danke,
Jens


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Ähnliche fragen