Bemerkung: Das Original ist neuer als diese Übersetzung.

Arbeit-bedürfende und voraussichtliche Pakete

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:

56 Pakete, die Hilfe benötigen, geordnet nach Alter oder nach Popularität

Voraussichtliche Pakete:

Beachten Sie: Diese Listen werden sechs mal am Tag aktualisiert; für aktuellere Informationen schauen Sie bitte im BTS nach Fehlerberichten gegen das Pseudo-Paket wnpp.

Auf der WNPP-Search-Website können Sie obige Informationen nach Paket, Beschreibung oder Typ sortiert durchsuchen.

Und obige Informationen in verschiedene Kategorien (basierend auf den Debtags) heruntergebrochen finden Sie auf der WNPP-by-tags-Website.

WNPP verwenden

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

Neue Einträge mit reportbug hinzufügen

Sie können dafür reportbug verwenden (apt-get install reportbug):

$ reportbug --email [email protected] wnpp
Using 'Name <[email protected]>' as your from address.
Getting status for wnpp...
Querying Debian bug tracking system for reports on wnpp
(Use ? for help at prompts.)
...

Ihnen 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?

1 ITP This is an Intent To Package. Please submit a package description
along with copyright and URL in such a report.

2 O The package has been Orphaned. It needs a new maintainer as soon
as possible.

3 RFA This is a Request for Adoption. Due to lack of time, resources,
interest or something similar, the current maintainer is asking for
someone else to maintain this package. He/she will maintain it in
the meantime, but perhaps not in the best possible way. In short:
the package needs a new maintainer.

4 RFH This is a Request For Help. The current maintainer wants to continue
to maintain this package, but he/she needs some help to do this, because
his/her time is limited or the package is quite big and needs several
maintainers.

5 RFP This is a Request For Package. You have found an interesting piece
of software and would like someone else to maintain it for Debian.
Please submit a package description along with copyright and URL in
such a report.

Choose the request type:

Nach Ihrer Wahl werden Sie nach dem Paketnamen gefragt:

Choose the request type: x
Please enter the proposed package name: PAKETNAME
Checking status database...

Dann werden Sie gefragt, ob Sie den Bericht abschicken wollen:

Report will be sent to Debian Bug Tracking System <[email protected]>
Submit this bug report (e to edit) [Y|n|i|e|?]?

Neue Einträge per E-Mail hinzufügen

Es ist ebenfalls möglich, Berichte/Fehler gegen WNPP per E-Mail zu senden. Das Format der E-Mail sollte wie folgt sein:

To: [email protected]
Subject: TAG: Paketname -- kurze Paketbeschreibung

Package: wnpp
Severity: siehe unten

Einige Informationen über das Paket. (Falls es ein ITP oder RFP ist, wird eine URL benötigt, von der das Paket (entweder die .deb oder die Originalquellen) heruntergeladen werden kann, wie auch die Lizenz betreffende Informationen.)

Die 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 ein Vorschlag, ein Paket zu bauen (Intent To Package). Bitte fügen Sie eine Paket-Beschreibung zusammen mit dem Copyright und einer URL in solch einen 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 einen Bericht ein.

Einträge löschen

Die Vorgehensweise zum Schließen eines solchen Fehlerberichts ist die folgende:

O Falls Sie ein Paket übernehmen, benennen Sie den Fehlerbericht um und ersetzen O mit 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 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 RFA mit 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 Besitzer (owner) des Fehlerberichts ein. Um das Paket tatsächlich zu übernehmen, laden Sie es mit Ihrem Namen im Maintainer:-Feld hoch, und schließen diesen Fehlerbericht, wenn das Paket installiert ist.

Falls Sie als Paketbetreuer entscheiden, das Paket verwaisen zu lassen, das Sie mit RFA markiert haben, benennen Sie bitte den Fehlerbericht um und ersetzen RFA mit O. Falls Sie Ihre Bitte zurückziehen, schließen Sie bitte den Fehlerbericht.
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 (RFA) oder es gleich als verwaist erklären wollen (O), benennen Sie bitte den Fehlerbericht um, statt einen neuen zu eröffnen.
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 RFP mit ITP, damit andere Personen wissen, dass an dem Paket bereits gearbeitet wird, und tragen sich als 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: [email protected]

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: wenn Sie Fehlerberichte anderen Paketen zuweisen, umbenennen oder den Besitzer ändern möchten, muss dies per E-Mail an den BTS-Kontroll-Server direkt geschehen, oder indem Sie eine E-Mail an den Fehlerbericht über seine Nummer ([email protected]) schicken und dabei Kontroll-Pseudo-Header benutzen, aber nicht indem Sie neue Fehlerberichte einreichen.

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 [email protected] erreichen.