Futuros paquetes o en los que se necesita trabajar

Los futuros paquetes o en los que se necesita trabajar, WNPP abreviadamente, es una lista de paquetes que necesitan nuevos responsables o que estarán en un futuro en Debian. Para seguir el estado real de estos paquetes, WNPP funciona actualmente como un pseudo-paquete mediante el sistema de seguimiento de fallos de Debian (BTS).


Paquetes que necesitan un nuevo responsable:

53 paquetes que necesitan ayuda, organizados por antigüedad o por popularidad

Futuros paquetes:

Nota: estas listas se actualizan seis veces al día; para obtener información más actualizada, por favor vaya a la página del pseudo-paquete wnpp en el BTS.

Puede buscar la información anterior por paquete, descripción o tipo en el sitio web de búsqueda WNPP.

Puede navegar por la información anterior desglosada en varias categorías (basada en debtags) en el sitio web WNPP-by-tags.


Uso de WNPP

Dado que se usa el BTS, todos los desarrolladores están familiarizados con los detalles técnicos sobre cómo enviar nueva información, modificarla, o cerrar las solicitudes pendientes. Por otro lado, para poder lograr un alto nivel de automatización, se deben seguir una serie de procedimientos.

Para poder enviar nueva información, se tiene que informar de un error en el pseudo paquete wnpp para cada (futuro) paquete afectado. Por favor, tenga en cuenta que sólo debe enviar un informe por cada paquete fuente en vez de un informe por cada paquete binario que se cree a partir de un paquete fuente.

Añadir nuevas entradas con reportbug

Puede usar reportbug (apt-get install reportbug):

$ reportbug --email nombreusuario@dominio.tld wnpp
Using 'Su Nombre <nombreusuario@dominio.tld>' as your from address.
Getting status for wnpp...
Querying Debian bug tracking system for reports on wnpp
(Use ? for help at prompts.)
...

Verá una lista de informes ya enviados al sistema WNPP que debería leer para evitar enviar un segundo informe para el mismo paquete.

Después de mostrarle la lista de informes anteriores, se le preguntará por el tipo de petición que va a hacer:

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. They 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:

Después de que realice su elección se le preguntará por el nombre del paquete:

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

Entonces se le pregunta si quiere enviar su petición:

Report will be sent to Debian Bug Tracking System <submit@bugs.debian.org>
Submit this bug report (e to edit) [Y|n|i|e|?]?

Añadir nuevas entradas mediante correo electrónico

También es posible enviar informes al sistema WNPP mediante el correo electrónico. El formato del envío debería ser:

To: submit@bugs.debian.org
Subject: [ETIQUETA (vea más abajo)]: nombre del paquete -- descripción corta del paquete

Package: wnpp
Severity: [GRAVEDAD (see below)]

Información concerniente al paquete. (Si esto es un ITP o RFP, se requiere una URL desde la que el paquete - el archivo .deb o la fuente original - se pueda obtener, así como información acerca de la licencia).

Las etiquetas que se pueden emplear y sus correspondientes importancias son:

ETIQUETA GRAVEDAD EXPLICACIÓN
O normal El paquete ha sido Abandonado. Necesita un nuevo responsable tan pronto como sea posible. Si el paquete tiene una prioridad mayor o igual que estándar (standard), la gravedad se debería establecer como importante (important).
RFA normal Esto es una Petición de Adopción. Debido a la falta de tiempo, recursos, interés o algo similar, el responsable actual está pidiendo que alguien mantenga este paquete. Lo mantendrá mientras tanto, pero quizás no de la mejor forma posible. En resumen: el paquete necesita un nuevo responsable.
RFH normal Esto es una Petición de ayuda (Request For Help). El responsable actual quiere continuar siendo responsable del paquete, pero necesita algo de ayuda para hacerlo, porque su tiempo es limitado o el paquete es realmente grande y necesita varios responsables.
ITP wishlist Esto es un Intento de Empaquetado. Por favor, envíe la descripción del paquete junto con el copyright y la URL en este tipo de informes.
RFP wishlist Esto es una Petición de Empaquetado. Alguien ha encontrado un programa interesante y le gustaría que otra persona fuese su responsable en Debian. Por favor, envíe una descripción del paquete junto con el copyright y la URL.

Aquí puede ver un informe de fallo de ejemplo.

Eliminar entradas

Los procedimientos para cerrar estos errores son:

O Si va a adoptar un paquete, retitule su error y reemplace O por ITA, de forma que otras personas puedan saber que el paquete está siendo adoptado, y se evite que se elimine de forma automática del archivo, y póngase como dueño del informe. Para adoptar realmente el paquete, debe enviarlo con su nombre en el campo Maintainer:, y añadir algo como * New maintainer (Closes: #númerodeerror) en el changelog del paquete de modo que el informe de error se cierre automáticamente una vez que el paquete se agregue; donde númerodeerror ha de ser reemplazado por el correspondiente número del informe de error. Además, antes de subir al archivo una nueva versión del paquete con usted como responsable, debería comprobar si existe una nueva versión del programa y tratar de arreglar los fallos que haya en ese programa.
RFA Si va a adoptar un paquete, retitule su error y sustituya RFA por ITA, de forma que otras personas puedan saber que el paquete está siendo adoptado, y se evite que se elimine de forma automática del archivo, y póngase como dueño del informe. Para adoptar realmente el paquete, debe subirlo con su nombre en el campo Maintainer: , y cerrar el error una vez que el paquete se agregue.

Si como mantenedor decide abandonar el paquete que marcó como RFA, por favor, cambie el título del informe de error y sustituya RFA por O. Si retira su petición, cierre el error.

RFH

Normalmente este error sólo lo debería cerrar el remitente, esto es, el responsable del paquete, si lo consideran obsoleto, una de dos o porque una o más personas han ofrecido (y proporcionado) su soporte o porque ahora cree que puede tratar el paquete él mismo.

Si usted, como responsable del paquete, decide cambiar el RFH a una petición de adopción (RFA) o si quiere dejar huérfano el paquete (O), por favor cambie el titulo del error en lugar de cerrarlo y rellenar uno nuevo.

ITP

Empaquete el software, cárguelo en el archivo y cierre el error una vez que el paquete se agregue.

Si cambia de idea, y ya no desea empaquetar este programa, cierre el error o cambie el título y reclasifíquelo como RFP, como considere que es mejor.

Si encuentra problemas al empaquetar el programa (por ejemplo, depende de otro programa que aún no se ha empaqueta y no tiene tiempo de empaquetar), puede registrar estos problemas como información adicional en el ITP, de forma que quede claro por donde va su trabajo de empaquetado.

RFP Si va a empaquetar este programa, cambie el informe de error para reemplazar RFP por ITP, de forma que otras personas puedan saber que el programa ya está siendo empaquetado, y póngase usted como dueño del informe. Empaquete el programa, cárguelo en el archivo y cierre el error cuando el paquete se agregue.

Si piensa que la lista de desarrolladores debiera enterarse del ITP, RFA o lo que sea, añada la cabecera

X-Debbugs-CC: debian-devel@lists.debian.org

al mensaje.

Por supuesto, la forma más fácil de cerrar estos informes de error es añadiendo una entrada en el archivo de cambios (changelog) del paquete, diciendo qué ha hecho y añadiendo (closes: bug#nnnnn) a ella. De esta forma el error se cerrará automáticamente cuando el nuevo paquete quede agregado dentro del archivo.

Atención: Si necesita reasignar, retitular o cambiar el dueño de un informe de error, debe hacerlo enviando un correo electrónico al robot de control del BTS directamente o a número de informe @bugs.debian.org y usando pseudo-cabecersas de control, pero no rellenando nuevos informes.

Aviso: Si un paquete permanece huérfano durante un tiempo muy largo, se examinará su situación para determinar si el paquete se necesita — si no, se pedirá a los mantenedores del FTP que lo eliminen de la versión «inestable».

Si por alguna razón necesita contactar con los responsables de WNPP, puede hacerlo en wnpp@debian.org.