Adoptar un paquete en Debian


Continuando con la temática de las entradas Preparar una máquina para el desarrollo de paquetes Debian y Usando git en el empaquetado de Debian, en este caso vamos a explicar los sencillos pasos que hay que dar para adoptar un paquete en Debian, para lo que seguiremos con nuestro ejemplo con dnsproxy.

¿Cómo podemos empezar a colaborar manteniendo paquetes en Debian?

Debian es una distribución de linux soportada por el trabajo de sus colaboradores voluntarios y esto hace que tenga bastantes peculiaridades. Un mantenedor de un paquete es la persona que decide libremente encargarse de modificar el software original y adaptarlo a las características necesarias para que funcione adecuadamente con el resto de paquetes de la distribución, lo cual es un trabajo meticuloso y bastante exigente desde el punto de vista técnico, además este trabajo se hace voluntariamente y en muchas ocasiones, por el simple placer de colaborar con el proyecto. Pero, ¿cómo se empieza? Es decir, si tengo las ganas, el tiempo y la disposición, ¿cómo hago para comenzar a colaborar como mantenedor con el proyecto?

Esta pregunta puede tener más de una respuesta, pero quizás la más sencilla es: busca un paquete que en estos momentos necesite tu ayuda en el sistema «Work Needed or Prospective Packages» (wnpp) Futuros paquetes o en los que se necesita trabajar. Cuando accedemos a ese enlace podremos ver paquetes en diferente situación:

  • Paquetes para los que se solicita ayuda. Paquetes para los que el actual mantenedor solicita ayuda, pero va a seguir manteniéndolo o co-manteniéndolo. Pueden darse diferentes circunstancias para que esto ocurra, pero la más frecuente es que el actual mantenedor no tiene el tiempo necesario para mantener completamente o como le gustaría el paquete, pero tampoco quiere dejar de colaborar en el mismo, por lo que solicita ayuda para mantenerlo más de una persona. Estos paquetes tienen un bug abierto marcado con RFH («Request For Help»).
  • Paquetes disponibles para ser adoptados. Son paquetes para los que se ha abierto un bug marcado como RFA («Request For Adoption»), en los que el actual mantenedor informa de que no puede o no tiene interés en seguir manteniendo el paquete, por lo que lo ofrece para que otro mantenedor se haga cargo de él, pero hasta que no se encuentre un nuevo mantenedor va a seguir manteniéndose, al menos haciendo cambios imprescindibles.
  • Paquetes huérfanos. Normalmente son paquetes que tras llevar un tiempo con el bug RFA abierto, no ha habido nadie en disposición a encargarse del mantenimiento y el anterior mantenedor llega un momento en el que decide dejar el mantenimiento, por lo que el paquete pasa a estado huérfano. Los paquetes huérfanos tienen un bug abierto marcado con O («Orphaned»). Que un paquete esté marcado como huérfano no significa siempre que deje de estar en debian, mientras no se informe de ningún fallo crítico, un paquete huérfano puede seguir incorporándose a debian testing y debian estable con la última versión publicada por el anterior mantenedor o incluso solucionar el fallo crítico y modificar puntualmente el paquete una persona que no quiere ser su mantenedor habitual, lo que se conoce como un «Non Maintainer Upload» o NMU (véase wiki.debian.org/NonMaintainerUpload para más detalles).

También aparecen en esta página los nuevos paquetes que no están en debian y se quieren incorporar, para lo que se utilizan los bugs etiquetados como RFP («Request For Package») para quien pide que se incluya un determinado paquete en Debian e ITP («Intent To Package») cuando se está trabajando en la incorporación de un paquete. Pero no nos centraremos en esta situación en este momento, ya que parece me parece más razonable comenzar a colaborar con Debian en alguno de los tres casos anteriores: RFH, RFA u O.

Otra forma de obtener información sobre paquetes en los que podemos echar una mano, es instalarnos el paquete how-can-i-help (¿Cómo puedo ayudar?) que nos irá dando información sobre nuevos paquetes etiquetados en wnpp cuando usamos APT.

RFH

Si queremos comenzar ayudando en un paquete marcado con RFH, simplemente tendremos que contestar al bug correspondiente informando de nuestra disposición a ayudar. El mantenedor normalmente se pondrá en contacto con nosotros y si finalmente terminamos colaborando en dicho paquete, nos incorporaremos como mantenedores o co-mantenedores del paquete poniendo nuestro nombre y dirección de correo en el campo «Maintainer:» o «Uploaders:», según corresponda, del fichero debian/control, aunque esto se explicará con más detalle en otra entrada. Esta situación es muy buena para empezar si el otro mantenedor está dispuestos a ayudarnos y a explicarnos el proceso de desarrollo, pero no siempre podemos contar con ello ya que precisamente que alguien haga un RFH puede ser porque no dispone del tiempo que quisiera para dedicarlo al proyecto (y eso puede incluir el ayudarnos a nosotros). Cada caso será un mundo y simplemente hasta que no hablemos con la persona que hace el RFH no podemos saber la situación real.

Adopción de un paquete

Tanto para los casos RFA como O el procedimiento es el mismo, respondemos por correo al bug correspondiente modificando la cabecera y sustituyendo la marca RFA/O por ITA («Intent To Adopt»). El bug marcado con ITA informa a las demás personas que hay alguien adoptando el paquete, pero no se considerará adoptado hasta que se publique una nueva versión del paquete en el archivo de Debian y se cierre el bug.

Vamos a verlo con el ejmplo de dnsproxy, que no tenía intención inicial de adoptar, pero es que uno tiene su corazoncito y con esta terminología que utiliza debian es difícil conocer un paquete huérfano y que no te entren ganas de adoptarlo :).

En el caso de dnsproxy el bug de wnpp que indica que está huérfano es el #876201, así que escribimos un mensaje de correo a la dirección 876201@bugs.debian.org, cambiando en el asunto «O» por «ITA» y explicando en el cuerpo del mensaje nuestra intención de adoptar el paquete y la información adicional que queramos añadir. En este caso yo he puesto la URL del repositorio de salsa:

Package: wnpp
Severity: normal

I intend to adopt the dnsproxy package.

The tentative repository for this package in salsa is:

https://salsa.debian.org/alberto/pkg-dnsproxy

De esta manera informamos públicamente de nuestra intención de adoptar el paquete. Desde este momento nos podemos considerar mantenedor del paquete y actuar como tal, aunque, como decíamos inicialmente, esto será realmente efectivo cuando modifiquemos apropiadamente el paquete debian y una nueva versión del paquete, incluyendo la información del nuevo mantenedor, se suba al archivo debian y se cierre el bug anterior.

Tipos de mantenedores y autorizaciones

Cualquiera puede colaborar en el desarrollo de paquetes de debian y no se necesita ningún permiso. Abrirse una cuenta en salsa, crear repositorios y adoptar un paquete es algo tan sencillo como lo que hemos explicado en esta entrada y las anteriores, pero eso no significa que el trabajo que realicen pase directamente al archivo de debian, es decir, lo que alguien suba a salsa no se utiliza directamente en los repositorios de debian. Hay un paso muy importante (que solo pueden realizar las personas autorizadas por el proyecto debian) que es subir un paquete al archivo. Vamos explicar a continuación los tipos de mantenedores que hay, que se distinguen precisamente por el tipo de autorización que tienen para subir paquetes al archivo:

  • «Sponsored Maintainer»: Persona que mantiene paquetes en debian pero que no está autorizado para subir al archivo, por lo que una vez ha publicado una versión nueva de un paquete debe pedir a alguien autorizado que lo haga. Si conoce a alguien que sea desarrollador debian (DD) puede ponerse en contacto directamente con esa persona y pedírselo, pero el proyecto pone a disposición de todos mentors.debian.net, un sitio web donde desarrolladores y mantenedores sin autorización pueden comunicarse y que proporciona un mecanismo elaborado para la revisión del paquete, elaboración de los bugs correspondientes de solicitud de ayuda y el resto de aspectos relacionados. La forma normal de empezar a colaborar en el empaquetado de debian es como «Sponsored Debian Maintainer» y lo más recomendable es hacerlo a través de mentors, ya que los desarrolladores que colaboran tienen la disposición de ayudar a los nuevos miembros de la comunidad con los problemas iniciales con el empaquetado.
  • «Debian Maintainer» (DM): Persona que tras llevar un tiempo manteniendo paquetes, ha demostrado ya que conoce el mecanismo de desarrollo suficientemente para no necesitar de supervisión, por lo que puede solicitar al proyecto convertirse en Debian Maintainer (DM), que es un puesto oficial dentro del proyecto y estará autorizado a subir algunos paquetes al archivo debian, normalmente los paquetes que mantiene. Es decir, en general un DM no puede ayudar a otros mantenedores a subir sus ficheros al archivo, ya que no tiene autorización para hacerlo.
  • «Debian Developer» (DD): Persona con suficiente experiencia en el desarrollo de paquetes que se considera un miembro de pleno derecho en el proyecto y puede subir cualquier paquete al archivo, aunque obviamente haciéndolo correctamente y respetando el desarrollo del resto. Algunos DDs participan voluntariamente como mentores de nuevos mantenedores en mentors.d.o y los ayudan en sus primeros pasos en el proyecto.

Continuaremos en las próximas entradas explicando los pasos para la actualización del paquete dnsproxy y su subida al archivo de Debian.

Adoptar un paquete en Debian

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s