Kapitel 3. Pflichten von Debian-Entwicklern

Inhaltsverzeichnis

3.1. Pflichten von Paketbetreuern
3.1.1. Auf die nächste Stable-Veröffentlichung hinarbeiten
3.1.2. Pakete in Stable betreuen
3.1.3. Verwalten release-kritischer Fehler
3.1.4. Abstimmung mit Originalautoren
3.2. Verwaltungspflichten
3.2.1. Verwaltung Ihrer Debian-Informationen
3.2.2. Verwalten Ihres öffentlichen Schlüssels
3.2.3. Abstimmungen
3.2.4. Elegant Urlaub machen
3.2.5. Sich zurückziehen
3.2.6. Nach dem Ausscheiden zurückkehren

Als Paketbetreuer sollen Sie Pakete hoher Qualität bereitstellen, die gut in das System integriert sind und die den Debian-Richtlinien folgen.

Es ist nicht ausreichend, 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 enthalten sein werden.

Konkreter ausgedrückt: Sie sollten überwachen, ob Ihre Pakete nach Testing (siehe Abschnitt 5.14, „Die Distribution Testing“) wandern. Wenn die Migration nach Ablauf der Testperiode nicht stattfindet, sollten Sie analysieren, warum und darauf hinarbeiten, dies zu beheben. Es könnte heißen, dass Sie Ihr Paket korrigieren 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 korrigiert 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.

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 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 Fehler 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 Fehlern 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“).

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. These bug reports should be forwarded to the upstream developers so that they can be fixed in a future upstream release. Usually it is best if you can do this, but alternatively, you may ask the bug submitter to do it.

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 Patches schicken, um Fehler im Ursprungsprogramm zu beheben – Sie sollten diese Patches auswerten und an die ursprünglichen Autoren weiterleiten.

In cases where a bug report is forwarded upstream, it may be helpful to remember that the bts-link service can help with synchronizing states between the upstream bug tracker and the Debian one.

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 den Quellcode bei der nächsten Version der Urprungsautoren nicht ändern müssen. Ganz gleich, welche Änderungen Sie möchten – versuchen Sie ein Verzweigen vom ursprünglichen Quellcode 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 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 und OpenPGP: optimales Vorgehen.

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. Aktualisierungen werden mindestens einmal monatlich von den debian-keyring-Paketbetreuern bearbeitet.

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, „Registering as a Debian member“ besprochen wurden.

Eine weiterreichende Erörterung der Debian-Schlüsselverwaltung können Sie in der Dokumentation des Pakets debian-keyring und auf http://keyring.debian.org/ finden.

Obwohl Debian nicht wirklich demokratisch ist, werden demokratische Prozesse benutzt, um das Führungspersonal zu wä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 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 herausgibt (und von allen Entwicklern wird erwartet, dass 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-signierter/verschlüsselter 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 geplanter 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 sind es auch weniger kritische Dinge, wegen derer Sie verhindert sein können, aber es ist trotzdem angemessen, andere darüber zu informieren.

Um andere Entwickler zu informieren, gibt es zwei Dinge, die Sie tun sollten. Zuerst senden Sie eine E-Mail an , in 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:

  1. Verwaisen Sie all Ihre Pakete, wie in Abschnitt 5.9.4, „Verwaisen von Paketen“ beschrieben.

  2. Senden Sie eine GPG-signierte E-Mail, die Ihren Rücktritt ankündigt, an .

  3. 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 mit den Wörtern »Debian RT« in der Betreffzeile (Groß- und Kleinschreibung spielt keine Rolle).

  4. Falls Sie E-Mails über einen »@debian.org«-E-Mail-Alias (z.B. press@debian.org) empfangen haben und möchten, dass das aufhört, öffnen Sie ein RT-Ticket für die Debian-Systemadministration. Senden Sie dazu eine E-Mail an , die irgendwo im Betreff »Debian RT« enthält und angibt, von welchen Alias Sie entfernt werden möchten.

Es ist wichtig, obigem Prozess zu folgen, da die Suche nach inaktiven Entwicklern und das Verwaisen ihrer Pakete erhebliche 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 wurde, und ansonsten als »disabled«. Zurückgetretene Entwickler mit einem »emeritus«-Konto können Ihr Konto wie folgt reaktivieren:

  • Kontaktieren Sie .

  • 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] Der Grund hierfür ist, dass die Nachricht einfach von Leuten ausgefiltert werden kann, die keine Urlaubsbenachrichtigungen lesen möchten.