Re: WNPP now on the BTS
Hi,
>> Anthony Towns <aj@azure.humbug.org.au> writes:
*sip*
After reading and rereading the Developer's Reference and the QA
docs, I did away with that oh-not-so-good WTO/ITO classifications and
added a RFA, as per your suggestion. Attached is the intended
documentation for the WNPP system.
Marcelo Work-Needing and Prospective Packages, WNPP for short, is a pseudo
package on the Debian Bug Tracking System (BTS) and its intention is to
track closely the real status of such things as prospective packages in
Debian and packages in need of new maintainers. Since it uses the BTS,
every developer is already familiar with the technical details, such as
submission of new information, modification of information or closing
of pending requests. On the other hand, in order to achieve the
highest level of automatization, some procedures have to be observed.
In order to submit new information, a bug has to be filed against the
wnpp pseudo package for each (prospective) package that is affected.
The format of the submission should be like this:
To: submit@bugs.debian.org
Subject: {TAG}: {package name} -- {short package description}
Package: wnpp
Severity: {see below}
{Some information about the package. If this is an ITP or RFP an
URL where the package can be downloaded from is required, as well
as information concerning its license.}
The tags to be used and their corresponding severities are:
O normal The package has been Orphaned. It needs a new
maintainer as soon as possible. If the package
as a Priority of standard, required or essential,
the severity should be set to important. If the
package remains in this orphaned state after one
month, the severity will be raised to important and
the ftp maintainers will be asked to move it to
project/orphaned.
RFA normal 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. Meanwhile the package is
being maintained, but perhaps not in the best
possible way. In short: the package needs a new
maintainer.
ITP wishlist Someone 'Intents To Package' this. Please submit
a package description along with copyright and URL
in such a report.
RFP wishlist This is a 'Request For Package'. Someone has found
an interesting piece of software and would like
someone else to package it for Debian and upload
it to the archives. Please submit a package
description along with copyright and URL in such
a report.
W wishlist The package has been withdrawn and can be found
in project/orphaned. Such reports should not be
submited directly, but instead should be a product
of retitling and downgrading 'O' reports.
The procedures for closing this bugs are as follow:
O adopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'ITA:' + the old title.
This is necessary in order for other people to know the
package is being adopted and to prevent its automatic removal
from the archive.
RFA adopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'ITA:' + the old title.
This is necessary in order for other people to know the
package is being adopted.
If you as the package maintainer decide to Orphan the package,
please retitle as necessary. If you withdraw your request,
please close the bug.
ITP package the software, upload to the main archive and close
this bug once the package has been installed.
If you change your mind, and no longer want to package this,
either close the bug or retitle and reclasify it as RFP, as
you see fit.
RFP package the software, upload to the main archive and close
this bug once the package has been installed. If you are
going to do this, retitle the bug as 'ITP:' + the old title.
W adopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'ITA:' + the old title.
This is necessary in order for other people to know the
package is being adopted.
Of course, the easiest way of closing bugs is to include the
appropiate entry on the changelog and append '(Closes: bug#nnnnn)' to
it. In this way, the bug will be closed at the time the new package
gets installed into the archive.
Reply to: