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:
- 140 Pakete zur Adoption, geordnet nach Betreuer oder nach Alter
- 1227 verwaiste Pakete, geordnet nach Alter
- 52 gerade übernommene Pakete, geordnet nach Alter oder nach Aktivität
56 Pakete, die Hilfe benötigen, geordnet nach Alter oder nach Popularität
- 2136 Pakete, an denen gearbeitet wird, geordnet nach Alter oder nach Aktivität
- 3449 angeforderte Pakete, geordnet nach Alter
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 ihr-name@domain.de wnppUsing 'Name <ihr-name@domain.de>' 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: xPlease enter the proposed package name: PAKETNAME
Checking status database...
Falls Ihr Bericht-Typ ITP (1) oder RFP (5) 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:
> EINE BESCHREIBUNG
Subject: ITP: PAKETNAME -- EINE BESCHREIBUNG
Package: wnpp
Version: N/A; reported 2011-04-28
Severity: wishlist
* Package name : PAKETNAME
Version : x.y.z
Upstream Author : Name <somebody@some.org>
* URL : http://www.some.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Description : EINE BESCHREIBUNG
-- System Information
...
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: x
Please enter the name of the package: PAKETNAME
Checking status database...
Subject: O: PAKETNAME -- KURZE BESCHREIBUNG
Package: wnpp
Version: N/A; reported 2011-04-28
Severity: normal
-- System Information
...
Sie 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>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: submit@bugs.debian.orgSubject: 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 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 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 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: 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 (xxxxxx@bugs.debian.org) 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 wnpp@debian.org erreichen.