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:
Software
que no se puede empaquetar
Nota: estas listas se actualizan diariamente. Para obtener información más actualizada, por favor vaya a la página del pseudo-paquete wnpp en el BTS.
reportbug
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. A pesar de esto, 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 que se vaya a preparar. Por favor, dese cuenta de 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.
reportbug
Puede usar reportbug (apt-get install reportbug):
$ reportbug --email nombreusuario@dominio.tld wnppVerá 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?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
Después de que realice su elección se le preguntará por el nombre del paquete:
Choose the request type: xSi el tipo de su petición es ITP (1) o RFP (4), se le preguntará también por una descripción corta y alguna información más sobre el paquete:
Please briefly describe this package; this should be an appropriate short description for the eventual package:Debajo de la línea Description
debería dar más información acerca
del paquete.
Si el tipo de su petición es O (2) o RFA (3), tiene que introducir el nombre del paquete.
Choose the request type: xDebería añadir alguna información acerca del mantenimiento del paquete, el estado del autor original y quizá la razón por la que quiere deshacerse del paquete.
Entonces se le pregunta si quiere enviar su petición:
Report will be sent to Debian Bug Tracking System <submit@bugs.debian.org>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.orgLas etiquetas que se pueden emplear y sus correspondientes importancias son:
| 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 copyrighty 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. |
Los procedimientos para cerrar estos errores son:
| O | Si va a adoptar un paquete, retitule su error
y reemplace Opor 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 changelogdel paquete de modo que el informe de error se cierre automáticamente una vez que el paquete sea instalado; 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 mantenedor, 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 RFApor 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 haya sido instalado. Si como responsable decide abandonar el paquete que marcó
como |
|---|---|
| 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 ( |
| ITP | Empaquete el software, cárguelo en el archivo y cierre el error una vez que el paquete haya sido instalado. 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 RFPpor 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 haya sido instalado. |
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 (nota: ésta es una cabecera real, no una pseudocabecera).
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 instalado dentro
del archivo.
Atención: Usted no puede reasignar, retitular o cambiar el dueño de un informe de error enviando un correo al número de error@bugs.debian.org, ni enviando nuevos informes. Tiene que enviar el mensaje apropiado al robot de control del BTS — ¡Lea las instrucciones para hacerlo!
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 Sid.
Si por alguna razón necesita contactar con los responsables de WNPP, puede hacerlo en wnpp@debian.org.