Kapitel 7. Jenseits der Paketierung

Inhaltsverzeichnis

7.1. Fehler berichten
7.1.1. Viele Fehler auf einmal berichten (Masseneinreichung von Fehlern)
7.1.1.1. Usertags
7.2. Qualitätssicherungsbestreben
7.2.1. Tägliche Arbeit
7.2.2. Treffen zur gemeinschaftlichen Behebung von Fehlern (Bug-Squashing-Parties)
7.3. Andere Paketbetreuer kontaktieren
7.4. Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen
7.5. Zusammenwirken mit zukünftigen Debian-Entwicklern
7.5.1. Pakete sponsern
7.5.1.1. Ein neues Paket sponsern
7.5.1.2. Eine Aktualisierung eines existierenden Pakets sponsern
7.5.2. Neue Entwickler befürworten
7.5.3. Handhabung von Bewerbungen neuer Betreuer

Debian ist weit mehr als nur Software zu paketieren und diese Pakete zu verwalten. Dieses Kapitel enthält Informationen über Wege, oft wirklich kritische Wege, fernab von einfachem Erstellen und Verwalten von Paketen zu Debian beizutragen.

Als eine Organisation von Freiwilligen verlässt sich Debian auf das Ermessen seiner Mitglieder, die auswählen, woran sie arbeiten möchten und was die kritischste Sache ist, in die sie Zeit investieren.

Bitte reichen Sie Fehlerberichte ein, wenn Sie Fehler in Debian-Paketen finden. Tatsächlich bilden Debian-Entwickler oftmals die erste Reihe der Tester. Fehler in den Paketen anderer Entwickler zu finden und zu melden, erhöht die Qualität von Debian.

Lesen Sie die Anweisungen zum Melden von Fehlern in der Debian-Fehlerdatenbank.

Versuchen Sie, den Fehlerbericht von einem normalen Benutzerkonto zu senden, auf dem Sie wahrscheinlich Mails empfangen können, so dass Leute, die weitere Informationen über den Fehler benötigen, Sie erreichen können. Senden Sie keine Fehlerberichte als Root.

Sie können ein Werkzeug wie reportbug(1) benutzen, um Fehlerberichte zu senden. Es kann den Prozess automatisieren und generell erleichtern.

Stellen Sie sicher, dass der Fehler nicht bereits gegen das Paket eingereicht wurde. Jedes Paket hat eine Fehlerliste, die einfach unter https://bugs.debian.org/Paketname einsehbar ist. Hilfswerkzeuge wie querybts(1) können Sie ebenfalls mit diesen Informationen versorgen (und reportbug wird normalerweise auch vor dem Versenden querybts aufrufen).

Versuchen Sie, Ihre Fehlerberichte an die ordnungsgemäße Stelle zu lenken. Wenn Ihr Fehlerbericht zum Beispiel von einem Paket handelt, das Dateien eines anderen Pakets überschreibt, prüfen Sie die Fehlerliste beider Pakete, um das Einreichen doppelter Fehlerberichte zu vermeiden.

Um zusätzliche Anerkennung zu erhalten, vereinigen Sie Fehler, die mehr als einmal berichtet wurden oder kennzeichnen Sie Fehler als »fixed«, die bereits behoben wurden. Beachten Sie, dass wenn Sie weder der Absender des Fehlers noch der Betreuer des Pakets sind, den Fehlerbericht nicht tatsächlich schließen sollten (es sei denn, Sie versichern sich der Erlaubnis des Betreuers).

Von Zeit zu Zeit möchten Sie vielleicht prüfen, was aus den Fehlerberichten geworden ist, die Sie versandt haben. Nutzen Sie diese Gelegenheit, um diejenigen zu schließen, die Sie nicht mehr reproduzieren können. Um herauszufinden, welche Fehlerberichte Sie versandt haben, besuchen Sie https://bugs.debian.org/from:Ihre-E-Mail-Adresse.

Das Berichten einer großen Anzahl von Fehlern für dasselbe Problem für eine große Zahl von Paketen — d.h. mehr als zehn — ist eine missbilligte Vorgehensweise. Unternehmen Sie alle nötigen Schritte, um das massenhafte Versenden von Fehlerberichten tunlichst zu vermeiden. Prüfen Sie zum Beispiel, ob das Problem automatisiert werden kann, indem Sie eine neue Prüfung zu lintian hinzufügen, so dass eine Fehlermeldung oder Warnung ausgegeben wird.

Falls Sie mehr als zehn Fehler auf einmal zum gleichen Thema berichten, wird empfohlen, dass Sie eine Nachricht an senden, in der Sie Ihre Absicht darlegen, ehe Sie den Bericht versenden und die Tatsache im Betreff Ihrer Mail erwähnen. Dies wird anderen Entwicklern ermöglichen zu prüfen, ob der Fehler ein echtes Problem darstellt. Zusätzlich wird es helfen, eine Situation zu vermeiden, in der mehrere Betreuer simultan beginnen, den gleichen Fehlerbericht einzureichen.

Bitte benutzen Sie das Programm dd-list und falls geeignet whodepends (aus dem Paket devscripts), um eine Liste aller betroffenen Pakete zu generieren und fügen sie die Ausgabe in Ihre Mail an ein.

Beachten Sie, wenn Sie viele Fehlerberichte mit dem gleichen Betreff senden möchten, dass Sie den Fehlerbericht an senden sollten, so dass der Fehlerbericht nicht an die Fehlerverteilungs-Maillingliste weitergeleitet wird.

The program mass-bug (from the package devscripts) can be used to file bug reports against a list of packages.

Auch wenn es eine eigene Gruppe für Qualitätssicherung gibt, sind QS-Aufgaben nicht ausschließlich dieser Gruppe vorbehalten. Sie können sich an dieser Aufgabe beteiligen, indem Sie Ihre Pakete so fehlerfrei und lintian-rein (siehe Abschnitt A.2.1, „lintian) wie möglich halten. Falls Sie finden, dies sei unmöglich, dann sollten Sie darüber nachdenken, einige Ihrer Pakete zu verwaisen (siehe Abschnitt 5.9.4, „Verwaisen von Paketen“). Alternativ könnten Sie andere Leute um Hilfe bitten, um den Rückstand, den Sie bei den Fehlern haben, aufzuholen (Sie können auf oder nach Hilfe fragen). Gleichzeitig können Sie sich nach Mitbetreuern umsehen (siehe Abschnitt 5.13, „Gemeinschaftliche Verwaltung“).

Von Zeit zu Zeit organisiert die QS-Gruppe Bug-Squashing-Parties, um so viele Probleme wie möglich zu beseitigen. Sie werden auf angekündigt und in der Ankündigung wird erklärt, auf welchem Bereich der Fokus der Party liegt: Üblicherweise konzentriert man sich auf release-kritische Fehler, aber es kann auch vorkommen, dass entschieden wird, bei der Fertigstellung eines Haupt-Upgrades zu helfen (wie einer neuen perl-Version, die ein Neukompilieren aller binären Module erfordert).

Die Regeln für Non-Maintainer-Uploads unterscheiden sich während der Parties, da die Ankündigung der Party als vorausgehende Ankündigung für den NMU angesehen wird. Falls Sie Pakete haben, die von der Party betroffen sind (da sie zum Beispiel release-kritische Fehler enthalten), sollten Sie eine Aktualisierung zu jedem zugehörigen Fehler senden, um seinen aktuellen Status zu erklären und was Sie von der Party erwarten. Falls Sie keinen NMU möchten, nicht an einem Patch interessiert sind oder den Fehler selbst bewältigen möchten, erklären Sie dies bitte im BTS.

Teilnehmer der Party haben besondere Regeln für NMUs. Sie können NMUs ohne vorherige Ankündigung durchführen, falls sie mindestens nach DELAYED/3-day hochladen. Alle anderen NMU-Regeln gelten wie üblich; sie sollten den Patch des NMUs an das BTS senden (an einen der offenen Fehler, der durch den NMU behoben wird oder an einen neuen Fehler, der als »fixed« gekennzeichnet wird). Sie sollten außerdem die besonderen Wünsche des Betreuers respektieren.

Falls Sie sich nicht sicher fühlen, einen NMU durchzuführen, senden Sie nur einen Patch an das BTS. Das ist weitaus besser als ein beschädigter NMU.

Während Ihres Lebens innerhalb von Debian werden Sie aus verschiedenen Gründen Kontakt zu anderen Betreuern haben. Sie möchten vielleicht neue Wege der Kooperation zwischen einer Zusammenstellung verwandter Pakete diskutieren oder einfach jemanden daran erinnern, dass eine neue Originalversion verfügbar ist, die Sie benötigen.

Die E-Mail-Adresse eines Paketbetreuers heraussuchen zu müssen, kann störend sein. Glücklicherweise gibt es einen einfachen E-Mail-Alias, Paket@packages.debian.org, der eine Möglichkeit bietet, dem Betreuer eine Mail zu schicken, ganz gleich wie seine E-Mail-Adresse (oder Adressen) auch sein mag. Ersetzen Sie Paket durch den Namen eines Quell- oder Binärpakets.

Möglicherweise sind Sie außerdem daran interessiert, Personen zu kontaktieren, die ein bestimmtes Quellpaket mittels Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“ abonniert haben. Sie können dazu die E-Mail-Adresse Paket@packages.qa.debian.org benutzen.

Falls Sie bemerken, dass es einem Paket an Betreuung mangelt, sollten Sie sicherstellen, dass der Betreuer aktiv ist und weiter an seinen Paketen arbeitet. Es ist möglich, dass er nicht mehr aktiv ist, sich aber nicht aus dem System abgemeldet hat. Andererseits ist es auch möglich, dass er nur eine Erinnerung braucht.

Es gibt ein einfaches System (die MIA-Datenbank), in der Informationen über Paketbetreuer aufgezeichnet werden, die als »Missing In Action« (vermisst) gelten. Wenn ein Mitglied der QS-Gruppe einen inaktiven Betreuer kontaktiert oder weitere Informationen über ihn findet, wird dies in der MIA-Datenbank aufgezeichnet. Das System ist unter /org/qa.debian.org/mia auf dem Rechner qa.debian.org verfügbar und kann mit dem Werkzeug mia-query abgefragt werden. Benutzen Sie mia-query --help, um zu erfahren, wie Sie Abfragen an die Datenbank richten. Falls Sie der Meinung sind, dass noch keine Informationen über einen inaktiven Betreuer aufgezeichnet wurde oder dass Sie weitere Informationen hinzufügen können, sollten Sie im Allgemeinen wie folgt verfahren:

Im ersten Schritt kontaktieren Sie den Betreuer höflich und warten eine angemessene Zeit auf eine Antwort. Es ist ziemlich schwer zu definieren, was eine angemessene Zeit ist, aber es ist wichtig zu berücksichtigen, dass das wahre Leben manchmal sehr hektisch ist. Eine Möglichkeit damit umzugehen wäre es, nach zwei Wochen eine Erinnerung zu senden.

Eine nicht funktionierende E-Mail-Adresse ist eine Verletzung der Debian Richtlinien . Falls eine E-Mail nicht zustellbar ist, melden Sie dies bitte als einen Fehler gegen das Paket, und informieren Sie das MIA-Team.

Falls der Betreuer nicht innerhalb von vier Wochen (einem Monat) antwortet, kann davon ausgegangen werden, dass wahrscheinlich keine Antwort mehr kommt. Falls dies geschieht, sollten Sie weiter nachforschen und versuchen so viele nützliche Informationen wie möglich über den betreffenden Betreuer zu sammeln. Dies beinhaltet:

  • die echelon-Informationen, die über debian.org Developers LDAP Search verfügbar sind. Sie geben an, wann der Entwickler zum letzten Mal an eine Debian-Mailingliste geschrieben hat. (Dies umfasst auch Mails über Uploads, die über die Liste verteilt wurden.) Denken Sie außerdem daran zu prüfen, ob der Betreuer in der Datenbank als im Urlaub befindlich markiert ist.

  • die Zahl der Pakete, für die dieser Betreuer verantwortlich ist und den Zustand dieser Pakete. Hauptsächlich, ob es release-kritische Fehler gibt, die seit Jahren offen sind. Ferner wie viele Fehler es im Allgemeinen sind. Ein weiterer wichtiger Teil der Informationen ist, ob für die Pakete NMUs durchgeführt werden und wenn, von wem.

  • Gibt es irgendeine Aktivität des Betreuers außerhalb von Debian? Er könnte zum Beispiel aktuell etwas an eine Nicht-Debian-Mailingliste oder an Newsgroups geschrieben haben.

Ein ziemliches Problem sind Pakete, die gesponsert wurden — der Betreuer ist kein offizieller Debian-Entwickler. Die echelon-Informationen sind nicht für gesponserte Leute verfügbar, so dass Sie beispielsweise den Debian-Entwickler finden und kontaktieren müssen, der das Paket tatsächlich hochgeladen hat. Angenommen, das Paket wurde signiert, dann ist er dennoch für das Paket verantwortlich und weiß wahrscheinlich, wie es mit der Person aussieht, die er sponserte.

Es ist außerdem erlaubt, eine Anfrage an zu senden und zu fragen, ob jemand etwas über den Verbleib des vermissten Betreuers weiß. Bitte senden Sie der Person, um die es geht, per Cc: eine Kopie.

Sobald Sie all dies gesammelt haben, können Sie kontaktieren. Die Leute hinter diesem Alias werden die von Ihnen bereitgestellten Informationen nutzen, um zu entscheiden, wie verfahren wird. Beispielsweise könnten sie eines oder alle Pakete des Betreuers verwaisen. Falls für ein Paket ein NMU durchgeführt wurde, könnten sie es vorziehen, vor dem Verwaisen des Pakets denjenigen zu kontaktieren, von dem der NMU durchgeführt wurde — vielleicht ist diese Person daran interessiert, das Paket zu übernehmen.

Eine abschließende Bemerkung: Bitte denken Sie daran, höflich zu bleiben. Alle hier sind Freiwillige und können nicht sämtliche Zeit Debian widmen. Außerdem wissen Sie nichts über die Situation der beteiligten Person. Vielleicht ist sie ernsthaft erkrankt oder sogar verstorben — Sie wissen nicht, wer auf der Empfängerseite ist. Stellen Sie sich vor, wie sich ein Verwandter fühlt, wenn er die E-Mail des Verstorbenen liest und eine sehr unhöfliche, böse oder vorwurfsvolle Nachricht findet!

Andererseits, trotz dass wir alle Freiwillige sind, geht ein Paketbetreuer auch eine Verpflichtung ein und hat deshalb auch eine Verantwortung, das Paket zu pflegen. So können Sie die Wichtigkeit eines übergeordneten Wohls betonen — falls die Betreuer keine Zeit oder kein Interesse mehr haben, sollten sie loslassen und das Paket jemandem mit mehr Zeit übergeben.

If you are interested in working on the MIA team, please have a look at the README file in /org/qa.debian.org/mia on qa.debian.org, where the technical details and the MIA procedures are documented, and contact .

Debians Erfolg hängt von der Fähigkeit ab, neue und talentierte Entwickler für sich zu gewinnen und zu halten. Wenn Sie ein erfahrener Entwickler sind, wird Ihnen empfohlen, sich am Prozess, neue Entwickler heranzuziehen, zu beteiligen.

Sponsern eines Pakets bedeutet, ein Paket für einen Betreuer hochzuladen, der nicht in der Lage ist, dies selbst zu tun. Es ist keine belanglose Angelegenheit, der Sponsor muss die Paketierung überprüfen und dafür sorgen, dass sie der hohen Qualität entspricht, die Debian anstrebt.

Debian-Entwickler können Pakete sponsoren. Debian-Betreuer können dies nicht.

Der Prozess, ein Paket zu sponsern ist:

  1. The maintainer prepares a source package (.dsc) and puts it online somewhere (like on mentors.debian.net) or even better, provides a link to a public VCS repository (see Abschnitt 4.4.5, „salsa.debian.org: Git repositories and collaborative development platform“) where the package is maintained.

  2. Der Sponsor lädt das Quellpaket herunter (oder führt einen Checkout durch).

  3. Der Sponsor prüft das Quellpaket. Falls er Probleme entdeckt, informiert er den Betreuer und bittet ihn, eine korrigierte Version bereitzustellen (der Prozess beginnt von vorn mit dem ersten Schritt).

  4. Der Sponsor konnte kein verbliebenes Problem finden. Er erstellt das Paket, signiert es und lädt es nach Debian hoch.

Bevor Sie die Einzelheiten erforschen, wie ein Paket gesponsert wird, sollten Sie sich selbst fragen, ob das vorgeschlagene Paket einen Mehrwert für Debian bringt.

Es gibt keine einfache Regel, um diese Frage zu beantworten, sie kann von vielen Faktoren abhängen: Ist die Code-Basis der Originalautoren ausgereift und nicht voller Sicherheitslücken? Gibt es bereits existierende Pakete, die die gleiche Aufgabe erledigen können und wie sind diese im Vergleich zu diesem neuen Paket? Gab es für dieses neue Paket eine Nachfrage durch Anwender und wie groß ist die Benutzerbasis? Wie aktiv sind die Entwickler des Originals?

Sie sollten außerdem sicherstellen, dass der zukünftige Betreuer ein guter Betreuer sein wird. Hat er bereits etwas Erfahrung mit anderen Paketen? Falls ja, leistet er bei ihnen gute Arbeit (überprüfen Sie einige Fehlerberichte)? Ist er vertraut mit dem Paket und dessen Programmiersprache? Verfügt er über die für dieses Paket nötigen Fähigkeiten? Falls nicht: ist er in der Lage, sie zu erlernen?

It's also a good idea to know where they stand with respect to Debian: do they agree with Debian's philosophy and do they intend to join Debian? Given how easy it is to become a Debian Member, you might want to only sponsor people who plan to join. That way you know from the start that you won't have to act as a sponsor indefinitely.

Neue Betreuer haben gewöhnlich bestimmte Schwierigkeiten bei der Erstellung von Debian-Paketen — dies ist ziemlich verständlich. Sie werden nicht immer alles richtig machen. Das ist der Grund, weshalb das Sponsern eines brandneuen Pakets in Debian eine sorgfältige Überprüfung notwendig macht. Manchmal sind mehrere Wiederholungen nötig, bis das Paket gut genug ist, um nach Debian hochgeladen zu werden. Daher impliziert ein Sponsor zu sein auch, ein Mentor zu sein.

Sponsern Sie ein Paket nie, ohne es zu überprüfen. Die Überprüfung eines neuen Pakets, die von den Ftpmasters vorgenommen wird, stellt nur sicher, dass die Software wirklich frei ist. Natürlich kommt es vor, dass sie über Paketierungsprobleme stolpern, aber das sollte wirklich nicht passieren. Es ist Ihre Aufgabe, dafür zu sorgen, dass das hochgeladene Paket mit Debians Richtlinien für freie Software übereinstimmt und von guter Qualität ist.

Das Erstellen des Pakets und Prüfen der Software ist Teil der Überprüfung, aber es reicht nicht aus. Der Rest dieses Abschnitts enthält eine unvollständige Liste von Punkten, die Sie bei Ihrer Überprüfung testen sollten. [8]

  • Prüfen Sie, ob der bereitgestellte Original-Tarball derselbe ist wie der, den der Originalautor verteilt (wenn die Quellen neu für Debian gepackt wurden, erstellen Sie selbst den geänderten Tarball).

  • Führen Sie lintian aus (siehe Abschnitt A.2.1, „lintian). Sie werden so gängige Probleme finden. Verifizieren Sie, dass jegliche lintian-overrides des Betreuers vollständig gerechtfertigt sind.

  • Führen Sie licensecheck aus (Teil von Abschnitt A.6.1, „devscripts) und überprüfen Sie, ob debian/copyright korrekt und komplett zu sein scheint. Suchen Sie nach Lizenzproblemen (wie Dateien mit »All rights reserved«-Kopfzeilen oder nicht DFSG-konformen Lizenzen). Bei dieser Aufgabe ist grep -ri Ihr Freund.

  • Erstellen Sie das Paket mit pbuilder (oder einem ähnlichen Werkzeug, siehe Abschnitt A.4.3, „pbuilder), um sicherzustellen, dass die Build-Abhängigkeiten vollständig sind.

  • Lesen Sie debian/control Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Abschnitt 6.2, „Optimale Vorgehensweisen für debian/control)? Sind die Abhängigkeiten vollständig?

  • Lesen Sie debian/rules Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Abschnitt 6.1, „Optimale Vorgehensweisen für debian/rules)? Sehen Sie mögliche Verbesserungen?

  • Lesen Sie die Betreuerskripte (preinst, postinst, prerm, postrm, config) Korrektur: Werden preinst/postrm funktionieren, wenn die Abhängigkeiten nicht installiert sind? Sind alle Skripte idempotent (d.h. können sie ohne Konsequenzen mehrmals ausführt werden)?

  • Überprüfen Sie jede Änderung an Originaldateien (entweder in .diff.gz, in debian/patches/ oder direkt in den Tarball debian für Binärdateien eingebettet). Sind sie gerechtfertigt? Sind sie ordentlich dokumentiert (mit DEP-3 für Patches)?

  • Fragen Sie sich für jede Datei, warum diese Datei dort ist und ob dies der richtige Weg ist, das gewünschte Ergebnis zu erzielen. Folgt der Betreuer den optimalen Vorgehensweisen beim Paketieren (siehe Kapitel 6, Optimale Vorgehensweise beim Paketieren)?

  • Erstellen Sie die Pakete, installieren Sie sie und probieren Sie die Software aus. Stellen Sie sicher, dass Sie die Pakete entfernen und vollständig entfernen können. Testen Sie sie eventuell mit piuparts.

Falls die Kontrolle keine Probleme offenbarte, können Sie das Paket erstellen und nach Debian hochladen. Denken Sie daran, dass, obwohl Sie nicht der Betreuer sind, Sie als Sponsor trotzdem auch für das verantwortlich sind, was Sie nach Debian hochladen. Daher sollten Sie das Paket durch das Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“ im Auge zu behalten.

Beachten Sie, dass Sie das Quellpaket nicht verändern sollten, um Ihren Namen in die Datei changelog oder control einzutragen. Das Feld Maintainer der Dateien control und changelog sollte die Person aufführen, die das Paket erstellte, d.h. den Gesponserten. Auf diese Art wird er die gesamten Nachrichten vom BTS erhalten.

Stattdessen sollten Sie dpkg-buildpackage anweisen, Ihren Schlüssel für die Signatur zu benutzen. Sie erreichen dies mit der Option -k:

dpkg-buildpackage -kSCHLÜSSEL-ID

Falls Sie debuild und debsign benutzen, können sie das sogar permanent in ~/.devscripts konfigurieren:

DEBSIGN_KEYID=SCHLÜSSEL-ID

Sie werden normalerweise davon ausgehen, dass das Paket bereits eine vollständige Überprüfung durchlief. Daher werden Sie, anstatt dies nochmals erneut zu tun, nur die Unterschiede zwischen der aktuellen und der neu vom Betreuer vorbereiteten Version sorgsam analysieren. Falls Sie die anfängliche Überprüfung nicht selbst durchgeführt haben, könnten Sie auch noch einen genaueren Blick darauf werfen, nur für den Fall, dass der erste Prüfer nachlässig war.

Damit Sie die Unterschiede untersuchen können, benötigen Sie beide Versionen. Laden Sie die aktuelle Version des Quellpakets herunter (mit apt-get source) und erstellen Sie es (oder laden Sie die aktuellen Binärpakete mit aptitude download herunter). Laden Sie das Quellpaket zum Sponsern (üblicherweise mit dget).

Lesen Sie das Änderungsprotokoll, damit Sie wissen, was Sie während der Überprüfung erwartet. Das Hauptwerkzeug, das Sie benutzen werden, ist debdiff (bereitgestellt vom Paket devscripts). Sie können es mit zwei Quellpaketen (.dsc-Dateien), zwei Binärpaketen oder zwei .changes-Dateien (dann wird es alle Binärpakete vergleichen, die in .changes aufgeführt sind) ausführen.

Falls Sie die Quellpakete vergleichen (ausschließlich der Originaldateien im Fall einer neuen Originalversion, zum Beispiel durch Filtern der Ausgabe von debdiff mit filterdiff -i '*/debian/*'), müssen Sie alle Änderungen verstehen und sie sollten ordentlich im Debian-Änderungsprotokoll dokumentiert sein.

Falls alles in Ordnung ist, erstellen Sie das Paket und vergleichen Sie die Binärpakete, um zu prüfen, ob die Änderungen am Quellpaket keine unerwarteten Folgen haben (wie einige versehentlich entfallenen Dateien, fehlende Abhängigkeiten etc.)

Sie möchten möglicherweise das Package-Tracking-System nutzen (siehe Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“), um zu überprüfen, ob der Betreuer nichts Wichtiges versäumt hat. Möglicherweise gibt es Übersetzungsaktualisierungen, die im BTS liegen und hätten integriert werden können. Möglicherweise wurde ein NMU des Pakets durchgeführt und der Betreuer vergaß, die Änderungen des NMUs in sein Paket einzubauen. Vielleicht ist ein release-kritischer Fehler unbehandelt geblieben und dies blockiert die Migration nach Testing. Falls Sie etwas finden, was (besser) erledigt werden könnte, ist es an der Zeit, ihm dies mitzuteilen, so dass er es das nächste Mal besser machen kann und dass er seine Verantwortlichkeiten besser versteht.

Falls Sie kein bedeutendes Problem gefunden haben, laden Sie die neue Version hoch. Andernfalls bitten Sie den Betreuer, Ihnen eine korrigierte Version zur Verfügung zu stellen.



[8] Sie können weitere Überprüfungen im Wiki finden, wo verschiedene Entwickler ihre eigenen Sponsoring-Prüflisten miteinander teilen.