Arbeit-bedürfende und voraussichtliche Pakete, kurz WNPP (Work-Needing and Prospective Packages), ist eine Liste von Paketen, die neue Betreuer benötigen, und von voraussichtlichen Paketen in Debian. Um den tatsächlichen Status dieser Dinge zeitnahe verfolgen zu können, wird WNPP zurzeit als Pseudo-Paket in der Fehlerdatenbank (BTS, Bug Tracking System) gehandhabt.
Pakete, die einen neuen Betreuer benötigen:
Software, die nicht als Paket ausgeliefert werden kann
Beachten Sie: Diese Listen werden täglich aktualisiert; für aktuellere Informationen schauen Sie bitte auf den wnpp Pseudo-Paket Eintrag im BTS.
Da es das BTS verwendet, ist jeder Entwickler bereits mit den technischen Details vertraut, wie zum Beispiel dem Einbringen neuer Informationen, der Modifizierung von Informationen oder dem Schließen von ausstehenden Anfragen. Um jedoch den höchsten Grad der Automation zu erreichen, müssen einige Prozeduren beachtet werden.
Um neue Informationen einzubringen, muss ein Fehler gegen das wnpp Pseudo-Paket für jedes (voraussichtliche) Paket gemeldet werden, das davon betroffen ist. Beachten Sie bitte, pro Quell-Paket nur einen Fehlerbericht abzuschicken. Das gilt auch für Quell-Pakete, aus denen mehrere Binär-Pakete gebaut werden.
reportbughinzufügen
Sie können dafür reportbug verwenden (apt-get install reportbug):
$ reportbug --email username@domain.tld wnppIhnen wird eine Liste von berichteten Fehlern gegen WNPP angezeigt, die Sie lesen sollten, um zu verhindern, dass ein zweiter Bericht für dasselbe Paket abgesetzt wird.
Nach der Fehlerliste werden Sie nach dem Bericht-Typ gefragt:
What sort of request is this?Intent To Package. Please submit a package description
Orphaned. It needs a new maintainer as soon
Request for Adoption. Due to lack of time, resources,
Request For Help. The current maintainer wants to continue
Request For Package. You have found an interesting piece
Nach Ihrer Wahl werden Sie nach dem Paketnamen gefragt:
Choose the request type: xFalls Ihr Bericht-Typ ITP (1) oder RFP (4) ist, werden Sie nach einer kurzen Beschreibung und weiteren Informationen über das Paket gefragt:
Please briefly describe this package; this should be an appropriate short description for the eventual package:Nach der Description
sollten Sie weitere Informationen über das Paket
angeben.
Falls Ihr Bericht-Typ O (2) oder RFA (3) ist, müssen Sie den Namen des Paketes eingeben.
Choose the request type: xSie sollten einige Informationen über das Betreuen des Paketes, die Upstream-Situation und eventuell einen Grund angeben, warum Sie das Paket weggeben.
Dann werden Sie gefragt, ob Sie den Bericht abschicken wollen:
Report will be sent to Debian Bug Tracking System <submit@bugs.debian.org>Es ist ebenfalls möglich, Berichte/Fehler gegen WNPP per E-Mail zu senden. Das Format der E-Mail sollte wie folgt sein:
To: submit@bugs.debian.orgDie Tags, die man verwenden soll, und ihre entsprechende Schweregrade (Severity) sind:
| O | normal | Das Paket ist verwaist (Orphaned). Es benötigt so bald wie möglich einen neuen Betreuer. Falls das Paket eine Priorität höher oder gleich standard hat, sollte die Schwere auf important gesetzt werden. |
|---|---|---|
| RFA | normal | Dies ist eine Freigabe zur Adoption (Request For Adoption). Wegen Zeit-, Ressourcenmangel oder etwas Ähnlichem sucht der aktuelle Betreuer nach einem neuen Betreuer für das Paket. Er/Sie wird es in der Zwischenzeit weiterbetreuen, aber möglicherweise nicht in der bestmöglichen Art und Weise. Kurz gesagt: Das Paket benötigt einen neuen Betreuer. |
| RFH | normal | Dies ist eine Bitte um Hilfe (Request For Help). Der aktuelle Betreuer möchte das Paket zwar immer noch betreuen, braucht aber Hilfe, sei es, weil er zu wenig Zeit hat, oder weil das Paket sehr groß ist und einfach mehrere Betreuer braucht. |
| ITP | wishlist | Dies ist eine Vorschlag, ein Paket zu bauen (Intent To Package). Bitte fügen Sie eine Paket-Beschreibung zusammen mit dem Copyright und einer URL in solch einem Bericht ein. |
| RFP | wishlist | Dies ist ein angefordertes Paket (Request For Package). Jemand hat eine interessante Software gefunden und würde es gerne sehen, wenn es jemand für Debian betreuen könnte. Bitte fügen Sie eine Paket-Beschreibung zusammen mit dem Copyright und einer URL in solch einem Bericht ein. |
Die Vorgehensweise zum Schließen eines solchen Fehlerberichts ist die folgende:
| O | Falls Sie ein Paket übernehmen, benennen Sie den Fehlerbericht
um und ersetzen Omit ITA, damit andere Personen wissen, dass das Paket bereits übernommen wird und seine automatische Löschung aus dem Archiv verhindert wird, und tragen sich als den Besitzer ( owner) des Fehlerberichts ein. Um das Paket tatsächlich zu übernehmen, laden Sie es mit Ihrem Namen im Maintainer: Feld hoch, und geben Sie etwas wie
* New maintainer (Closes: #Fehlernummer)
im changelog des Pakets an, um diesen Fehler automatisch zu schließen,
wenn das Paket installiert wurde; wobei Fehlernummer die
Fehlernummer des entsprechenden Fehlerberichts sein muss. Des Weiteren
sollten Sie prüfen, bevor Sie ein neues Paket mit Ihnen als Betreuer
hochladen, ob es ein neues Upstream-Release gibt und Sie sollten
versuchen, die ausstehenden Fehler zu beheben.
|
|---|---|
| RFA | Falls Sie ein Paket übernehmen, benennen Sie den Fehlerbericht
um und ersetzen Falls Sie als Paketbetreuer entscheiden, das Paket verwaisen zu
lassen, das Sie mit |
| RFH |
Dieser Fehlerbericht sollte nur durch denjenigen geschlossen werden, der ihn auch eröffnet hat, also den Paketbetreuer, wenn er ihn als erledigt ansieht, sei es, weil einer oder mehrere angeboten haben, ihm zu helfen (und dies auch getan haben) oder weil er denkt, dass er das Paket doch alleine betreuen kann. Falls Sie als Paketbetreuer entscheiden, das Paket doch zur
Adoption freizugeben ( |
| ITP | Bauen Sie ein Paket aus der Software, laden Sie sie hoch und schließen diesen Fehlerbericht, wenn es installiert ist. Falls Sie Ihre Meinung geändert haben und nicht länger daran arbeiten wollen, schließen Sie entweder den Fehlerbericht oder benennen Sie ihn auf RFP um, je nach dem, was Sie für sinnvoller halten. Falls beim Paketieren des Programms Probleme auftauchen (zum Beispiel, dass es von einem anderen, noch-nicht-paketierten Programm abhängt, und Sie dafür keine Zeit haben), sollten Sie diese Probleme als zusätzliche Information in dem ITP aufzeichnen, so dass klar ist, was mit Ihren Paketier-Bemühungen gerade passiert. |
| RFP | Falls Sie ein so markiertes Paket bauen wollen, benennen Sie den
Fehlerbericht um und ersetzen RFPmit ITP, damit andere Personen wissen, dass an dem Paket bereits gearbeitet wird, und tragen sich als den Besitzer ( owner) des Fehlerberichts ein. Dann bauen Sie das Paket, laden es hoch und schließen diesen Fehlerbericht, wenn das Paket installiert ist. |
Falls Sie denken, dass die Entwickler-Mailingliste von Ihrem ITP, RFA oder sonstigem informiert werden soll, fügen Sie die Kopfzeile
X-Debbugs-CC: debian-devel@lists.debian.org
in Ihre E-Mail ein.
Natürlich ist der einfachste Weg, diese Fehlerberichte zu schließen, einen Eintrag im changelog des Paketes zu platzieren, der sagt, was Sie getan haben und daran (closes: bug#nnnnn) anzuhängen. Auf diese Art wird der Fehlerbericht automatisch geschlossen, nachdem das neue Paket in das Archiv installiert wurde.
Vorsicht: Sie können die Fehlerberichte weder umbenennen, anderen Paketen zuweisen oder sich als Besitzer eintragen, indem Sie an die Fehlerberichts-Nummer @bugs.debian.org schreiben, noch durch das Absetzen eines neuen Berichts. Sie müssen eine passende E-Mail an den BTS-Control-Bot schicken – lesen Sie die Anleitung dazu!
Beachten Sie: Falls ein Paket für eine sehr lange Zeit verwaist ist, werden wir die Situation untersuchen und entscheiden, ob das Paket überhaupt noch benötigt wird – falls nicht, werden die FTP-Betreuer gebeten, das Paket aus unstable zu löschen.
Falls Sie aus irgend einem Grund die WNPP-Betreuer kontaktieren müssen, können Sie sie unter wnpp@debian.org erreichen.