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.

If, for any reason, you aren't able to fix an RC bug in a package of yours within 2 weeks (for example due to time constraints, or because it's difficult to fix), you should mention it clearly in the bug report and you should tag the bug help to invite other volunteers to chime in. Be aware that RC bugs are frequently the targets of Non-Maintainer Uploads (see Non-Maintainer Uploads (NMUs)) because they can block the testing migration of many packages.

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. Idealerweise bekommen Sie das Upstream-Projekt dazu sich per subscribe für Debian Paket Tracker Notifications einzuschreiben für ihre Software in Debian.

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.

Da die meisten Upstream-Projekte heutzutage git als Versionskontrollsystem verwenden, bietet git-buildpackage den einfachsten Weg um Patches in Debian so zu erstellen und zu verwalten, dass die Patches beim Upstream-Projekt eingereicht werden können. Für Details lesen Sie die git-buildpackage Handbuchseiten über die Nutzung von pq um debian/patches als Git-Commits zu schreiben und zu testen und mit dem Git-Remote upstreamvcs einfach Patches zu und von dem Upstream Git-Zweig zu cherry-picken.

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

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see Debian-Maschinen). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ and OpenPGP Best Practices.

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. Entscheidungsfindung

Neben den Aspekten unterhalb von Abstimmungen beschrieben ist Debian dichter an einer Do-ocracy, als an einer Demokratie. Allgemein betrachtet bedeutet dies, dass Entscheidungen von den Leuten getroffen werden, die die Arbeit machen. In den meisten Fällen sind das Paketbetreuer und DPL delegates. Öffentliche Diskussion ist:

  • während ermutigt und ggf. als Beitrag zur Entscheidungsfindung geschätzt,

  • nicht notwendig für eine Entscheidung,

  • und kann keine Entscheidung überstimmen (dies ist nur durch eine Generalresolution möglich oder durch die Eskalation an das Debian Technical Committee).

Im Sinne einer Do-ocracy wird von Mitgliedern der Debian Gemeinschaft erwartet, dass sie in konkreter und konstruktiver Weise beitragen, anstatt von anderen zu erwarten irgendeine Art von Arbeit für sie zu leisten.

For more on the social aspects of contributing to Debian, you are strongly encouraged to read the Debian Community Guidelines at https://people.debian.org/~enrico/dcg/

3.2.5. 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.6. 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. entfernen Sie sich von Team-Wiki-Seiten oder Salsa-Gruppen.

  • Login into https://nm.debian.org/ and then open https://nm.debian.org/process/emeritus to request emeritus status and write a goodbye message that will be automatically posted on debian-private.

    Salsa is used as authentication provider to the NM site, in case you run into problems opening the retirement process yourself, contact NM front desk using nm@debian.org

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.7. 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:

  • Melden Sie sich unter nm.debian.org mit Ihren Salsa-Anmeldedaten an.

  • Folgen Sie dem Nach dem Ausscheiden zurückkehren Wizard.

  • 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).

In case you run into problems contact nm@debian.org for further instructions.

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