3. Pflichten von Debian-Entwicklern

3.1. Pflichten von Paketbetreuern

Als Paketbetreuer sollten Sie qualitativ hochwertige Pakete bereitstellen, die gut in das System integriert sind und den Debian-Richtlinien entsprechen.

3.1.1. Auf die nächste `Stable`-Veröffentlichung hinarbeiten

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 Die Distribution Testing) wandern. Wenn die Migration nach Ablauf der Testperiode nicht stattfindet, sollten Sie analysieren warum diese nicht erfolgt und darauf hinarbeiten, dies zu beheben. Es könnte heißen, dass Sie Ihr Paket korrigieren müssen (z.B. im Fall Release-kritischer Fehler oder wenn das Bauen auf einigen Architekturen fehlschlägt), aber es kann auch heißen, dass andere Pakete aktualisiert bzw. korrigiert (oder manchmal auch aus Testing entfernt) werden müssen, um bei einer Transition zu helfen, in denen Ihr Paket aufgrund von Abhängigkeiten involviert ist. Das Release-Team kann Ihnen einige Informationen zu den aktuellen Blockern einer bestimmten Transition geben, wenn Sie diese nicht identifizieren können.

3.1.2. Pakete in `Stable` betreuen

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 korrigierte Version bereitzustellen (siehe 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 Sonderfall Uploads in die Distributionen Stable und Oldstable).

3.1.3. Verwalten Release-kritischer Fehler

Sie sollten Fehlerberichte zu Ihren Paketen generell so erledigen, wie es in 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 schlechtesten 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 einzubringen. Seien Sie sich bewusst, dass Release-kritische Fehler oft das Ziel von Uploads durch Nicht-Betreuer ("Non-Maintainer Uploads", siehe 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 QA-Team oft als Zeichen interpretiert, dass der Betreuer verschwunden ist, ohne sein Paket ordentlich zu verwaisen. Das MIA-Team (Missing In Action Team) könnte außerdem eingeschaltet werden, was dazu führen könnte, dass Ihre Pakete verwaist werden (siehe Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen).

3.1.4. Abstimmung mit Originalautoren

Ein großer Teil Ihrer Arbeit als Debian-Betreuer wird darin bestehen, mit den Upstream-Entwicklern in Kontakt zu bleiben. Benutzer von Debian melden manchmal Fehler, die nicht spezifisch für die Debian Distribution sind, an unser Fehlerverfolgungssystem (oft BTS genannt was Bug Tracking System bedeutet). Diese Fehlerberichte sollten an die Upstream-Entwickler weitergeleitet werden, damit diese in einer zukünftigen Upstream-Version behoben werden können. Normalerweise ist es am besten, wenn Sie dies tun können, aber alternativ können Sie auch den Fehler-Übermittler bitten dies zu tun.

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 Fällen, in denen ein Fehlerbericht nach Upstream weitergeleitet wird, kann es hilfreich sein, dass der BTS-Link-Dienst zur Synchronisierung von Bug-Reports zwischen dem Upstream- und dem Debian BTS-Dienst benutzt wird.

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 Originalautoren nicht ändern müssen. Ganz gleich, welche Änderungen Sie möchten – versuchen Sie ein Forken 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.

3.2. Verwaltungspflichten

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 reibungslos läuft.

3.2.1. Verwaltung Ihrer Debian-Informationen

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-Mail Adresse 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 Die Entwicklerdatenbank.

3.2.2. Verwalten Ihres öffentlichen Schlüssels

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 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 https://keyring.debian.org/replacing_keys.html.

Es werden die gleichen Schlüssel-Extrahierungsroutinen angewandt, wie sie unter Registrierung als Debian Mitglied besprochen wurden.

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

3.2.3. Abstimmungen

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 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 heraus gibt (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 OpenPGP-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.

3.2.4. Elegant Urlaub machen

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 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 debian-private@lists.debian.org, in der Sie [VAC] vor den Betreff Ihrer Nachricht schreiben [1] 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 Die Entwicklerdatenbank 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 OpenPGP-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.

3.2.5. Sich zurückziehen

Falls Sie das Debian-Projekt verlassen wollen, sollten Sie die folgenden Schritte einhalten:

Verwaisen Sie all Ihre Pakete wie in Verwaisen von Paketen beschrieben.
Entfernen Sie sich aus Uploader-Feldern für Co- oder Team-betreute Pakete.
Falls Sie E-Mails über einen "@debian.org" E-Mail Alias (z.B. press@debian.org) empfangen haben und möchten aus diesem entfernt werden, öffnen Sie ein RT-Ticket für die Debian-Systemadministration. Senden Sie dazu eine E-Mail an admin@rt.debian.org, die irgendwo im Betreff "Debian RT" enthält und angibt, von welchen Alias Sie entfernt werden möchten.
Bitte denken Sie daran, sich auch aus Teams zurückzuziehen, z.B. entferne Dich von Team-Wiki-Seiten oder Salsa-Gruppen.
Verwenden Sie den Link https://nm.debian.org/process/emeritus, um sich auf nm.debian.org anzumelden, den Emeritus-Status anzufordern und eine Abschiedsnachricht zu schreiben, die automatisch auf debian-private Mailingliste veröffentlicht wird.

Für die Authentifizierung an der NM-Seite ist ein SSO-Browserzertifikat erforderlich. Sie können diese auf https://sso.debian.org generieren.

Wenn Sie Probleme haben, den Ruhestand selbst zu starten, kontaktieren sie über nm@debian.org das NM-Frontdesk.

Es ist wichtig obigem Prozess zu folgen, da die Suche nach inaktiven Entwicklern und das Verwaisen derer Pakete erhebliche Zeit kostet und Mühe bereitet.

3.2.6. Nach dem Ausscheiden zurückkehren

Das Konto eines zurückgetretenen Entwicklers ist als "Emeritus" markiert, wenn dem Prozess in Sich zurückziehen gefolgt wurde und ansonsten als "Removed". Zurückgetretene Entwickler mit einem "Emeritus"-Konto können Ihr Konto wie folgt reaktivieren:

Zugang zu einem Salsa Account erhalten (entweder indem Sie sich die Anmeldeinformationen für Ihr altes Gastkonto gemerkt haben oder indem Sie ein neues Konto anfordern, welches auf der SSO Debian Wikiseite beschrieben ist.
Schreiben einer E-Mail an nm@debian.org zum Erhalt weitere Anweisungen.
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).

Zurückgetretene Entwickler mit einem "Removed" Konto müssen den NM-Prozess erneut durchlaufen.