Inhaltsverzeichnis
Als Paketbetreuer sollen Sie Pakete hoher Qualität bereitstellen, die gut in das System integriert sind und die den Debian-Richtlinien folgen.
Es reicht nicht aus, Pakete hoher Qualität in unstable
bereitzustellen, die meisten Anwender werden nur von Ihren Paketen
profitieren, wenn Sie Teil der nächsten
stable
-Veröffentlichung sind. Es wird daher von Ihnen
erwartet, dass Sie mit dem Release-Team zusammenarbeiten, um
sicherzustellen, dass Ihre Pakete dort berücksichtigt werden.
Konkreter ausgedrückt, sollten Sie überwachen, ob Ihre Pakete nach
testing
(siehe Abschnitt 5.13, „Die Distribution Testing“) wandern. Wenn
die Migration nicht nach der Testperiode stattfindet, sollten Sie
analysieren, warum und darauf hinarbeiten, dies zu beheben. Es könnte
heißen, das Sie Ihr Paket reparieren müssen (im Fall release-kritischer
Fehler oder wenn das Bauen auf einigen Architekturen fehlschlägt), aber es
kann auch heißen, dass andere Pakete aktualisiert (oder repariert oder aus
testing
entfernt) werden müssen, um bei einem Übergang zu
helfen, in den Ihr Paket aufgrund von Abhängigkeiten verstrickt ist. Das
Release-Team könnte Ihnen einige Informationen liefern, was derzeit einen
gegebenen Übergang blockiert, falls Sie das nicht erkennen können.
Die meiste Arbeit von Paketbetreuern geht in das Bereitstellen
aktualisierter Paketversionen in unstable
, aber ihre
Aufgabe bedingt auch, sich um Pakete in der aktuellen Veröffentlichung von
stable
zu kümmern.
Obwohl von Änderungen in stable
abgeraten wird, sind
diese dennoch möglich. Immer wenn ein Sicherheitsproblem gemeldet wird,
sollten Sie mit dem Sicherheits-Team zusammenarbeiten, um eine reparierte
Version bereitzustellen (siehe Abschnitt 5.8.5, „Handhabung von sicherheitsrelevanten Fehlern“). Wenn Fehler
des Schweregrads »important« (oder höher) gemeldet werden, sollten Sie in
Betracht ziehen, eine gezielte Fehlerbehebung zur Verfügung zu stellen. Sie
können das stable
-Release-Team fragen, ob es eine solche
Aktualisierung akzeptieren würde und dann einen
stable
-Upload vorbereiten (siehe Abschnitt 5.5.1, „Ein Sonderfall sind Uploads in die Distributionen stable
und oldstable
.“).
Sie sollten Fehlerberichte zu Ihren Paketen generell so erledigen, wie es in
Abschnitt 5.8, „Fehlerbehandlung“ beschrieben wird. Es gibt jedoch eine
spezielle Fehlerkategorie, auf die Sie besonders Acht geben sollten –
sogenannte release-kritische Fehler (release critical bugs/RC-Fehler). Alle
Fehlerberichte, mit den Schweregrad critical
,
grave
oder serious
machen das Paket
ungeeignet für eine Aufnahme in die nächste
stable
-Veröffentlichung. Sie können daher die
Debian-Veröffentlichung verzögern (wenn sie ein Paket in
testing
beeinflussen) oder Migrationen nach
testing
blockieren (wenn sie nur ein Paket in
unstable
beeinflussen). Im schlimmsten Fall führen Sie
zum Entfernen des Pakets. Daher müssen diese Fehler so schnell wie möglich
behoben werden.
Falls Sie aus irgend einem Grund nicht in der Lage sind, den Fehler in einem
Paket innerhalb von zwei Wochen zu beheben (zum Beispiel aus Termingründen
oder weil er schwer zu beheben ist), sollten Sie es klar im Fehlerbericht
vermerken und den Fahler mit help
kennzeichnen, um
Freiwillige einzuladen, sich einzuschalten. Seien Sie sich bewusst, dass
release-kritische Fehler oft das Ziel von Uploads durch Nicht-Betreuer
(»Non-Maintainer Uploads«, siehe Abschnitt 5.11, „Non-Maintainer Uploads (NMUs)“) sind, da sie die
Migration vieler Pakete nach testing
blockieren können.
Mangel an Aufmerksamkeit gegenüber release-kritischen Fehler wird vom Release-Team oft als Zeichen interpretiert, dass der Betreuer verschwunden ist, ohne sein Paket ordentlich zu verwaisen. Das MIA-Team könnte außerdem eingeschaltet werden, was dazu führen könnte, dass Ihre Pakete verwaist werden (siehe Abschnitt 7.4, „Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen“).
Ein Großteil Ihrer Arbeit als Debian-Betreuer wird darin bestehen, mit den Autoren des Programms Kontakt zu halten. Manchmal melden Debian-Anwender Fehler an die Debian-Fehlerdatenbank, die nicht Debian-spezifisch sind. Sie müssen diese Fehler an die Programmautoren weiterleiten, so dass die Programmautoren sie in einer zukünftigen Veröffentlichung beheben können.
Obwohl es nicht Ihre Arbeit ist, nicht Debian-spezifische Fehler zu beheben, können Sie dies dennoch tun, wenn Sie dazu in der Lage sind. Wenn Sie solche Fehler beheben, stellen Sie sicher, dass Sie ihre Korrekturen auch an die ursprünglichen Betreuer weiterleiten. Debian-Anwender und -Entwickler werden manchmal Patchs schicken, um Fehler im Ursprungsprogramm zu beheben – Sie sollten diese Patchs auswerten und an die ursprünglichen Autoren weiterleiten.
Falls Sie die ursprünglichen Quellen verändern müssen, um ein den Richtlinien entsprechendes Paket zu erstellen, dann sollten Sie freundlich eine Korrektur vorschlagen, die dort eingefügt werden kann, so dass Sie die Quellen bei der nächsten Version der Urprungsautoren nicht ändern müssen. Ganz gleich, welche Änderungen sie möchten – versuchen Sie ein Verzweigen von den ursprünglichen Quellen zu vermeiden.
Wenn Sie der Ansicht sind, dass die ursprünglichen Entwickler Debian oder der Gemeinschaft rund um freie Software ablehnend gegenüber stehen, könnten Sie es sich nochmal überlegen, ob Sie die Software in Debian einbringen möchten. Manchmal sind es die gesellschaftlichen Kosten höher, als der Gewinn, den die Software mitbringt.
Ein Projekt der Größe von Debian beruht auf einer Verwaltungsinfrastruktur, um über alles den Überblick zu behalten. Als Projektmitglied haben Sie einige Pflichten, um sicherzustellen, dass alles glatt läuft.
Es gibt unter https://db.debian.org/ eine LDAP-Datenbank, die Informationen über Debian-Entwickler enthält. Sie sollten Ihre Informationen dort eintragen und bei Änderungen aktualisieren. Stellen Sie insbesondere sicher, dass Ihre Weiterleitungsadresse für Ihre debian.org-E-Mails immer aktuell ist. Das gilt auch für die Adresse, zu der Ihre »debian-private«-E-Mails versendet werden, wenn Sie sich auch dort angemeldet haben.
Um weitere Informationen über die Datenbank zu erhalten, lesen Sie bitte Abschnitt 4.5, „Die Entwicklerdatenbank“.
Gehen Sie sehr vorsichtig mit Ihren privaten Schlüsseln um. Legen Sie sie nicht auf öffentlichen Servern oder Maschinen mit mehreren Benutzern ab, wie den Debian-Servern (siehe Abschnitt 4.4, „Debian-Maschinen“). Sichern Sie Ihre Schlüssel. Behalten Sie eine Kopie offline. Lesen Sie die Dokumentation, die Ihrer Software beiliegt. Lesen Sie die PGP-FAQ.
Sie müssen nicht nur dafür sorgen, dass Ihr Schlüssel sicher vor Diebstahl ist, sondern auch, dass er nicht verloren geht. Generieren Sie Ihr Widerrufs-Zertifikat und erstellen Sie eine Kopie davon (am besten in Papierform). Dies wird benötigt, wenn Sie Ihren Schlüssel verloren haben.
Falls Sie Ihrem öffentlichen Schlüssel Signaturen oder Benutzerkennungen
hinzufügen, können Sie den Debian-Schlüsselring aktualisieren, indem Sie
Ihren Schlüssel an den Schlüsselserver unter
keyring.debian.org
senden.
Wenn Sie einen komplett neuen Schlüssel hinzufügen oder einen alten entfernen möchten, benötigen Sie den durch einen anderen Entwickler neu signierten Schlüssel. Falls der alte Schlüssel kompromittiert oder ungültig ist, müssen Sie außerdem das Widerrufs-Zertifikat hinzufügen. Falls es keinen vernünftigen Grund für einen neuen Schlüssel gibt, können die Betreuer des Schlüsselrings den neuen Schlüssel ablehnen. Details finden Sie unter http://keyring.debian.org/replacing_keys.html.
Es werden die gleichen Schlüssel-Extrahierungsroutinen angewandt, wie sie unter Abschnitt 2.3, „Als Debian-Entwickler registrieren“ besprochen wurden.
Eine weiterreichende Erörterung der Debian-Schlüsselverwaltung können Sie in
der Dokumentation des Pakets debian-keyring
finden.
Obwohl Debian nicht wirklich demokratisch ist, werden demokratische Prozesse benutzt, um das Führungspersonal auszuwählen und generellen Entschlüssen zuzustimmen. Diese Prozeduren sind durch die Debian-Verfassung definiert.
Im Gegensatz zur jährlichen Wahl des Projektleiters werden keine
regelmäßigen Abstimmungen abgehalten und wenn doch, dann nicht einfach
so. Jeder Vorschlag wird zuerst auf der Mailingliste <debian-vote@lists.debian.org>
besprochen und benötigt mehrere Befürworter, bevor der Projektsekretär die
Abstimmungsprozedur in Gang setzt.
Sie müssen vor der Abstimmung nicht alle Diskussionen verfolgen, da der
Sekretär mehrere Aufrufe zur Abstimmung auf <debian-devel-announce@lists.debian.org>
herausgibt (Und von allen Entwicklern wird erwartet, das sie diese Liste
abonniert haben). Demokratie funktioniert nicht richtig, wenn die Leute
nicht an Abstimmungen teilnehmen, daher wird allen Entwicklern empfohlen
abzustimmen. Die Abstimmung wird mittels GPG-signierte/verschlüsselte
E-Mails durchgeführt.
Die Liste aller(früheren und aktuellen) Vorschläge ist auf der Seite Debian-Abstimmungs-Informationen verfügbar, ebenso die Informationen, wie Vorschläge gemacht und unterstützt werden und darüber abgestimmt wird.
Es ist bei Entwicklern üblich, dass es Zeiten gibt, in denen sie abwesend sind, entweder wegen geplanten Ferien oder einfach, weil sie unter anderer Arbeit begraben sind. Am wichtigsten ist, dass Sie daran denken, andere Entwickler über Ihren Urlaub zu informieren, damit diese bei Problemen mit Ihren Paketen oder anderweitigen Pflichten im Projekt die erforderlichen Maßnahmen ergreifen können.
Üblicherweise bedeutet dies, dass andere Entwickler ein NMU (siehe Abschnitt 5.11, „Non-Maintainer Uploads (NMUs)“) Ihres Pakets durchführen dürfen, weil ein großes Problem (release-kritischer Fehler, Sicherheitsaktualisierung etc.) auftritt während Sie in Ferien sind. Manchmal ist dies etwas weniger kritisches, aber es ist trotzdem angemessen, andere wissen zu lassen, dass Sie nicht verfügbar sind.
Um andere Entwickler zu informieren, gibt es zwei Dinge, die Sie tun
sollten. Zuerst senden Sie eine E-Mail an
<debian-private@lists.debian.org>
bei der Sie [VAC] vor den Betreff
Ihrer Nachricht schreiben[2] und die Dauer
angeben, wie lange Sie Urlaub machen. Sie können außerdem einige besondere
Anweisungen geben, was beim Auftreten von Fehlern zu tun ist.
Das andere, was Sie tun sollten, ist, sich selbst in der LDAP-Entwicklerdatenbank von Debian als abwesend zu kennzeichnen (auf diese Information können nur Debian-Entwickler zugreifen). Vergessen Sie nicht, die Urlaubskennzeichnung zu entfernen, wenn Sie wieder zurück sind.
Idealerweise sollten Sie sich auf den GPG-Koordinierungsseiten anmelden, wenn Sie Urlaub buchen und prüfen, ob es dort jemanden gibt, der eine Signatur benötigt. Dies ist besonders dann wichtig, wenn Leute an exotische Orte fahren, an denen es noch keine Entwickler gibt, aber Leute, die an einer Bewerbung interessiert sind.
Falls Sie das Debian-Projekt verlassen wollen, sollten Sie die folgenden Schritte einhalten:
Verwaisen Sie all Ihre Pakete, wie in Abschnitt 5.9.4, „Verwaisen von Paketen“ beschrieben.
Senden Sie eine GPG-signierte E-Mail mit den Gründen, weshalb Sie das
Projekt verlassen, an <debian-private@lists.debian.org>
.
Benachrichtigen Sie die Debian-Schlüsselverwalter über Ihren Weggang, indem
Sie ein Ticket in Debian-RT öffnen. Dies geschieht durch Senden einer E-Mail
an <keyring@rt.debian.org>
mit den Wörtern »Debian RT« in der Betreffzeile (Groß-
und Kleinschreibung spielt keine Rolle).
Es ist wichtig, obigem Prozess zu folgen, da die Suche nach inaktiven Entwicklern und das Verwaisen ihrer Pakete spürbar Zeit und Mühe kostet.
Das Konto eines zurückgetretenen Entwicklers ist als »emeritus« markiert, wenn dem Prozess in Abschnitt 3.2.5, „Sich zurückziehen“ gefolgt wird und ansonsten als »disabled«. Zurückgetretene Entwickler mit einem »emeritus«-Konto können Ihr Konto wie folgt neu aktivieren:
Kontaktieren Sie <da-manager@debian.org>
.
Durchlaufen Sie den verkürzten NM-Prozess (um sicherzustellen, dass der zurückgekehrte Entwickler noch immer die wichtigen Teile von P&P – »Philosophie und Prozeduren« und T&S – »Aufgaben und Fertigkeiten« kennt).
Beweisen Sie, dass Sie immer noch den mit dem Konto verbundenen GPG-Schlüssel kontrollieren oder stellen Sie den Nachweis Ihrer Identität für einen neuen GPG-Schlüssel mit mindestens zwei Signaturen anderer Entwickler bereit.
Zurückgetretene Entwickler mit einem »disabled«-Konto müssen den NM-Prozess erneut durchlaufen.
[2] Dies geschieht so, dass die Nachricht einfach von Leuten gefiltert werden kann, die keine Urlaubsbenachrichtigungen lesen möchten.