Los abundantes resultados finales producidos por el proyecto Debian derivan simultáneamente del trabajo de sus desarrolladores experimentados en la infraestructura, trabajo individual o grupal de desarrolladores en paquetes Debian y comentarios y sugerencias de usuarios.
1.3.1. Los desarrolladores Debian
Los desarrolladores Debian tienen varias responsabilidades y, como miembros oficiales del proyecto, tienen una gran influencia en la dirección del mismo. Un desarrollador Debian generalmente es responsable de al menos un paquete, pero según su disponibilidad y voluntad son libres de involucrarse en varios grupos asumiendo, así, más responsabilidades dentro del proyecto.
La manutención de paquetes es una actividad relativamente organizada, muy documentada o inclusive reglamentada. Debe, de hecho, adherirse a todos los estándares establecidos por la
Normativa Debian («Debian Policy»). Afortunadamente, existen muchas herramientas que facilitan el trabajo de los desarrolladores. Ellos pueden, entonces, concentrarse en las particularidades de su paquete y en tareas más complejas como la corrección de errores.
La Normativa («Policy») es un elemento esencial del proyecto Debian, establece las normas que garantizan tanto la calidad de los paquetes como también la interoperabilidad perfecta de la distribución. Gracias a este documento, Debian se mantiene consistente a pesar de su gigantesco tamaño. La Normativa no está escrita en piedra sino que evoluciona continuamente gracias a propuestas formuladas en la lista de correo
[email protected]. Las modificaciones acordadas por todas las partes interesadas son aceptadas y aplicadas al texto por un grupo reducido de desarrolladores que no tienen responsabilidad editorial (sólo incluyen las modificaciones aceptadas por los desarrolladores Debian que son miembros de la lista antes mencionada). Puede leer las correcciones propuestas siendo discutidas en el sistema de seguimiento de errores:
The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.
This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (
DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.
Específicamente, el líder realmente tiene autoridad: sus votos deciden votaciones empatadas, pueden tomar decisiones sobre aquello que no esté a cargo de alguien más y pueden delegar parte de sus responsabilidades.
Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.
La constitución también define un «comité técnico». El rol esencial de este comité es tomar decisiones en asuntos técnicos cuando los desarrolladores involucrados no llegaron a un acuerdo entre ellos. De lo contrario, el comité tiene un rol de consejero para cualquier desarrollador que no tome una decisión en una cuestión de la que son responsables. Es importante notar que el comité sólo se involucra cuando alguna de las partes así lo solicita.
Por último, la constitución define la posición de «secretario del proyecto» quien está a cargo de organizar las votaciones relacionadas a las varias elecciones y resoluciones generales.
The “general resolution” (
GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a
Condorcet method (more specifically, the Schulze method). For further details see:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.
Esta es la única forma en que ganará sus insignias: haga algo útil y muestre que ha trabajado bien. Muchos equipos «administrativos» en Debian funcionan por cooptación, prefiriendo voluntarios que ya han realizado contribuciones palpables y demostrado ser competentes. La naturaleza pública del trabajo de estos equipos hace posible que nuevos colaboradores la observen y empiecen a ayudar sin ningún privilegio especial. Esta es la razón por la que Debian es normalmente descripto como una «meritocracia».
Este método de operaciones es efectivo y garantiza la calidad de los contribuyentes en los equipos «clave» de Debian. Este método dista de ser perfecto y ocasionalmente algunos no lo aceptan. La selección de desarrolladores aceptados en los grupos puede parecer arbitraria o incluso injusta. Lo que es más, no todos tienen la misma definición de los servicios esperados de estos equipos. Para algunos es inaceptable tener que esperar ocho días para la inclusión de un nuevo paquete en Debian, mientras que otros esperarán pacientemente por tres semanas sin problemas. Por ello, regularmente hay quejas sobre la «calidad de servicio» de algunos equipos por aquellos que están descontentos.
1.3.2. El papel activo de los usuarios
Uno se podría preguntar si es relevante mencionar a los usuarios entre aquellos que trabajan dentro del proyecto Debian, pero la respuesta es un sí definitivo: tienen un papel crítico en el proyecto. Lejos de ser «pasivos», algunos usuarios utilizan versiones de desarrollo de Debian y reportan fallos regularmente para indicar problemas. Otros van más allá aún y envían ideas para mejoras reportando errores con gravedad «wishlist» o inclusive envían correcciones al código fuente, llamados «parches» (revise el recuadro
Sección 1.3.2.3, “Enviar arreglos”).
1.3.2.1. Informar de errores
La herramienta fundamental para enviar errores en Debian es el sistema de seguimiento de errores de Debian («BTS» por sus siglas en inglés), usada por grandes porciones del proyecto. La parte pública (la interfaz web) permite a los usuarios ver todos los errores reportados con la opción de mostrar una lista ordenada de los errores de acuerdo a diversos criterios de selección tales como: paquete afectado, gravedad, estado, dirección del que lo ha reportado, dirección del desarrollador a cargo del error, etiquetas, etc. También es posible navegar por el listado histórico completo de todos los debates sobre cada uno de los errores.
Bajo la superficie, el BTS de Debian se basa en el email: toda la información que almacena proviene de mensajes enviados por las personas involucradas. Cualquier correo enviado a
[email protected] será asignado a la historia del error número 12345. Personas autorizadas pueden «cerrar» un error escribiendo un mensaje que describa las razones de la decisión para cerrarlo a
[email protected] (un reporte es cerrado cuando el problema indicado es resuelto o ya no es relevante). Un nuevo error se puede reportar enviando un correo a
[email protected] siguiendo un formato específico que identifica el paquete en cuestión. La dirección
[email protected] permite editar toda la «metainformación» relacionada al reporte.
El BTS de Debian tiene otras características y funciones como el uso de etiquetas para clasificar errores. Para más información revise
Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report, without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).
Esta herramienta siempre apunta primero a las versiones de desarrollo, donde se solucionarán los errores. En efecto, no se introducen cambios en una versión estable de Debian salvo por unas pocas excepciones, como actualizaciones de seguridad u otras actualizaciones importantes (si, por ejemplo, un paquete no funciona en absoluto). La corrección de un error menor en un paquete de Debian deberá, entonces, esperar a la próxima versión estable.
1.3.2.2. Traducción y documentación
Además, a muchos usuarios satisfechos con el servicio ofrecido por Debian les gustaría hacer su propia contribución al proyecto. Como no todos tienen la experiencia necesaria en programación pueden elegir ayudar con la traducción y revisión de la documentación. Existen listas de correo específicas a cada idioma para coordinar este trabajo.
Los usuarios más avanzados podrían ser capaces de proporcionar un arreglo a un programa enviando un parche.
Un parche es un archivo que describe los cambios realizados a uno o más archivos de referencia. En particular, contendrá una lista de las líneas eliminadas o agregadas al código así como también (además) líneas tomadas del texto de referencia que ponen en contexto las modificaciones (permiten identificar la ubicación de los cambios en caso que los números de línea hayan cambiado).
La herramienta utilizada para aplicar las modificaciones en uno de estos archivos es patch. La herramienta que los crea es diff y se utiliza de la siguiente forma:
$ diff -u archivo.antiguo archivo.nuevo >archivo.patch
El archivo archivo.patch contiene las instrucciones para cambiar el contendo de archivo.antiguo al contenido de archivo.nuevo. Podemos enviarlo a alguien que luego puede utilizarlo para crear archivo.nuevo de los otros dos de la siguiente forma:
$ patch -p0 archivo.viejo <archivo.patch
El archivo archivo.viejo es ahora idéntico a archivo.nuevo.
In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.
Si bien la salida de git diff es un archivo que puede compartirse con otros desarrolladores, normalmente hay mejores formas de enviar cambios. Si los desarrolladores prefieren recibir parches por correo electrónico, normalmente quieren parches generados con git format-patch para que puedan ser integrados directamente en el repositorio con git am. Esto preserva la información de metadatos de los «commits» y permite compartir varios «commits» de golpe.
Este proceso de trabajo por correo electrónico es todavía popular, pero tiende a ser reemplazado por el uso de merge requests (o pull requests) cuando el software se aloja en una plataforma como GitHub o GitLab —y Debian usa GitLab en su servidor salsa.debian.org—. En estos sistemas, una vez creada una cuenta, bifurcas (fork) el repositorio, creando efectivamente una copia del repositorio en tu cuenta, y después puedes clonar ese repositorio y subir (push) tus propios cambios a este. Desde ahí, la interfaz web te sugerirá que envíes un merge request, notificando a los desarrolladores de tus cambios, facilitándoles la revisión y aceptación de tus cambios con un simple clic.
1.3.2.4. Otras formas de colaborar
Todos estos mecanismos de colaboración son más eficientes con el comportamiento de los usuarios. Lejos de ser una colección de personas aisladas, los usuarios son una verdadera comunidad en la que ocurren numerosos intercambios. Notamos especialmente la impresionante actividad en la lista de correo para discusión de usuarios
[email protected] (el
Capítulo 7, Resolución de problemas y búsqueda de información relevante discute esto en más detalle).
No sólo los usuarios se ayudan entre ellos (y a otros) con problemas técnicos que los afectan directamente sino que también discuten las mejores formas para contribuir con el proyecto Debian y ayudar moverlo adelante — discusiones que frecuentemente resultan en sugerencias para mejoras.
Como Debian no gasta fondos en capañas de promoción sus usuarios cumplen un papel esencial en su difusión, asegurando su fama con el boca a boca.
Este método funciona bastante bien ya que se encuentran fanáticos de Debian en todos los niveles de la comunidad de software libre: desde festivales de instalación (talleres en los que usuarios experimentados ayudan a novatos a instalar el sistema) organizado por grupos de usuarios Linux (
LUG por sus siglas en inglés), hasta puestos de la asociación en grandes convenciones técnicas que tienen que ver con Linux, etc.
Los voluntarios elaboran carteles, folletos, pegatinas y otros materiales promocionales útiles para el proyecto que ponen a disposición de todo el mundo, y que Debian ofrece libremente en su sitio web y en su wiki:
1.3.3. Teams, Blends, and Sub-Projects
From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.
1.3.3.1. Existing Debian Sub-Projects and Blends
To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;
Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;
Debian-Med, por Andreas Tille, dedicada a la campo de la medicina;
Debian Multimedia, which deals with audio and multimedia work;
Debian GIS, which takes care of Geographical Information Systems applications and users;
Debian Astro, for both professionals and hobby astronomers;
Debian Science, working on providing researchers and scientists a better experience using Debian;
Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;
Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;
DebiChem, centrado en la Química, proporciona paquetes y programas de química.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.
1.3.3.2. Grupos administrativos
La mayoría de los equipos administrativos son relativamente cerrados y solo reclutan miembros por cooptación. La mejor forma de convertirse en miembro de uno es asistir inteligentemente a miembros actuales demostrándoles que uno entiende sus objetivos y métodos de operación.
Los ftpmasters están a cargo del archivo oficial de paquetes Debian. Mantienen el programa que recibe los paquetes enviados por desarrolladores y los almacena automáticamente en el servidor de referencia luego de algunas revisiones (ftp-master.debian.org).
Antes de incluirlo en el conjunto de paquetes existentes, deben también verificar la licencia de todo paquete nuevo para asegurar que Debian puede distribuirlos. Cuando un desarrollador desea eliminar un paquete, se dirige a este equipo a través del sistema de seguimiento de errores y el «pseudopaquete» ftp.debian.org.
El equipo
Debian System Administrators (
DSA, «administradores de sistemas de Debian»,
[email protected]) es, como uno esperaría, responsable de la administración de los muchos servidores utilizados por el proyecto. Aseguran el funcionamiento óptimo de todos los servicios base (DNS, sitio web, correo, consola, etc.), instalar software pedido por desarrolladores Debian y tomar todas las precauciones necesarias en cuanto a seguridad.
Los «listmasters» administran el servidor de email que gerencian las listas de correo. Crean nuevas listas, manejan rechazos (anuncios de fallo de entrega) y mantienen filtros de spam (correo masivo no solicitado).
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker,
salsa.debian.org (GitLab server, see sidebar
HERRAMIENTA GitLab, alojamiento de repositorios Git y mucho más), the services available on
qa.debian.org,
lintian.debian.org,
buildd.debian.org,
cdimage.debian.org, etc.
1.3.3.3. Equipos de desarrollo, equipos transversales
A diferencia de los equipos de administradores los equipos de desarrollo son más abiertos, incluso a los colaboradores externos. Incluso si Debian no tuviera vocación de crear software, el proyecto necesita algunos programas concretos para alcanzar sus objetivos. Desarrollado por supuesto bajo una licencia de software libre, estas herramientas hacen uso de métodos probados en otras partes del mundo del software libre.
Debian desarrolló poco software propio, pero algunos programas asumieron roles centrales y su fama se propagó más allá de los alcances del proyecto. Son buenos ejemplos dpkg, el programa de administración de paquetes de Debian (su nombre es, de hecho, una abreviación de paquete Debian - «Debian PacKaGe» y generalmente se lo nombra «dee-package» en inglés) y apt, una herramienta para instalar automáticamente cualquier paquete Debian y sus dependencias garantizando la consistencia del sistema luego de la actualización (su nombre es acrónimo de herramienta avanzada para paquetes - «Advance Package Tool»). Sus equipos son, sin embargo, mucho más pequeños ya que se necesitan habilidades de programación algo avanzadas para entender el funcionamiento de este tipo de programas.
El equipo más importante probablemente sea el del programa de instalación de Debian,
debian-installer, que ha llevado a cabo una obra de increíbles proporciones desde su concepción en 2001. Fueron necesarios numerosos colaboradores ya que es difícil escribir un único programa capaz de instalar Debian en una docena de arquitecturas diferentes. Cada una con su propio mecanismo de arranque y su propio gestor de arranque. Todo este trabajo es coordinado en la lista de correo
[email protected] bajo la dirección de Cyril Brulebois.
El (pequeñísimo) equipo del programa debian-cd tiene un objetivo mucho más modesto. Muchos contribuyentes «pequeños» son responsables de su arquitectura ya que el desarrollador principal no puede conocer todas sus sutilezas ni la manera exacta para iniciar el programa de instalación desde el CD-ROM.
Muchos equipos tienen que colaborar con otros en la actividad de empaquetado:
[email protected] intenta, por ejemplo, garantizar la calidad en todos los niveles del proyecto Debian. La lista
[email protected] desarrolla la normativa Debian de acuerdo con las propuestas de todos lados. Los equipos encargados de cada arquitectura (
debian-architecture@lists.debian.org) compila todos los paquetes, adaptándolos a su arquitectura particular si es necesario.
Otros equipos administran los paquetes más importantes con el fin de asegurar el mantenimiento sin colocar una carga demasiado pesada sólo sobre un par de hombros; este es el caso de la biblioteca C y
[email protected], el compilador C en la lista
[email protected], Xorg en
[email protected] (este grupo también es conocido como la Fuerza de Ataque X — «X Strike Force»).
