3. Pflichten von Debian-Entwicklern

3.1. Pflichten von Paketbetreuern

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

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

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 Ein Sonderfall sind 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 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 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 Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen).

3.1.4. Abstimmung mit Originalautoren

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.

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

If you need to add a completely new key or remove an old key, you need to get the new key signed by another developer. If the old key is compromised or invalid, you also have to add the revocation certificate. If there is no real reason for a new key, the Keyring Maintainers might reject the new key. Details can be found at https://keyring.debian.org/replacing_keys.html.

Es werden die gleichen Schlüssel-Extrahierungsroutinen angewandt, wie sie unter Registering as a Debian member besprochen wurden.

You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package and the https://keyring.debian.org/ site.

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

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

3.2.5. Sich zurückziehen

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

  • Orphan all your packages, as described in Verwaisen von Paketen.

  • Remove yourself from uploaders for co- or team-maintained packages.

  • 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 admin@rt.debian.org, die irgendwo im Betreff »Debian RT« enthält und angibt, von welchen Alias Sie entfernt werden möchten.

  • Please remember to also retire from teams, e.g. remove yourself from team wiki pages or salsa groups.

  • Use the link https://nm.debian.org/process/emeritus to log in to nm.debian.org, request emeritus status and write a goodbye message that will be automatically posted on debian-private.

    Authentification to the NM site requires an SSO browser certificate. You can generate them on https://sso.debian.org.

    In the 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 ihrer Pakete erhebliche Zeit und Mühe kostet.

3.2.6. Nach dem Ausscheiden zurückkehren

A retired developer's account is marked as "emeritus" when the process in Sich zurückziehen is followed, and "removed" otherwise. Retired developers with an "emeritus" account can get their account re-activated as follows:

  • Get access to an alioth account (either by remembering the credentials for your old guest account or by requesting a new one as decribed at SSO Debian wiki page.
  • Mail nm@debian.org for further instructions.
  • 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).

Retired developers with a "removed" account need to go through full NM again.

[1]Der Grund hierfür ist, dass die Nachricht einfach von Leuten ausgefiltert werden kann, die keine Urlaubsbenachrichtigungen lesen möchten.