Product SiteDocumentation Site

1.3. El funcionamiento interno del proyecto Debian

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

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.
Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.
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 . 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, Jonathan Carter, and Andreas Tille.
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 puts 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».
This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.

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 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 (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 siguiendo un formato específico que identifica el paquete en cuestión. La dirección 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, e.g. using the bts command). 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.

1.3.2.3. Enviar arreglos

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.
This email-based workflow is still popular, but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.

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 (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. Equipos, "Blends" y subproyectos

Debian está organizado, desde sus comienzos, sobre el concepto de paquetes fuente, cada uno con su mantenedor o grupo de mantenedores. Con el tiempo, han aparecido numerosos equipos de trabajo asegurando la administración de la infraestructura, la organización de tareas no específicas a un paquete en particular (control de calidad, normativa de Debian, instalador, etc.), con los últimos equipos creciendo alrededor de subproyectos.

1.3.3.1. Subproyectos Debian y Blends existentes

¡Para cada uno, su Debian! Un subproyecto es un grupo de voluntarios interesados en adaptar Debian a una necesidad específica. Además de seleccionar un subgrupo de programas destinados a un dominio particular (educación, medicina, creación multimedia, etc.) los subproyectos están involucrados en mejorar paquetes existentes, crear nuevos paquetes de software, adaptar el instalador, crear documentación específica y más. Si bien un "blend" puede no ser exactamente lo mismo, funciona de manera bastante similar y también intenta brindar una solución para grupos de personas que tienen la intención de usar Debian para un dominio en particular. Se podría decir que "Debian Pure Blends" es el sucesor de los subproyectos.
A continuación se muestra una pequeña selección de los Debian Pure Blends actuales:
  • Debian Junior, offering an appealing and easy to use Debian system for children;
  • Debian Edu, focused on the creation of a specialized distribution for the academic and educational world;
  • Debian Med, dedicated to the medical field;
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, tanto para profesionales como para astrónomos aficionados;
  • Debian Science, finalmente, que trabaja para proporcionar a investigadores y científicos una mejor experiencia usando Debian;
  • Freedombox, creado para desarrollar, diseñar y promover servidores personales que ejecuten software libre para comunicaciones privadas y personales;
  • Debian Games, que ofrece juegos en Debian desde arcade y aventura hasta simulación y estrategia;
  • DebiChem, centrado en la Química, proporciona paquetes y programas de química.
El número de proyectos seguramente continuará creciendo con el tiempo y la mejor percepción de las ventajas de los Debian Pure Blends. Completamente apoyados en la infraestructura Debian existente pueden enfocar su trabajo con un valor añadido real sin preocuparse por mantenerse sincronizados con Debian ya que se desarrollan dentro del proyecto.

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», ) 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 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: intenta, por ejemplo, garantizar la calidad en todos los niveles del proyecto Debian. La lista desarrolla la normativa Debian de acuerdo con las propuestas de todos lados. Los equipos encargados de cada arquitectura () 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 , el compilador C en la lista , Xorg en (este grupo también es conocido como la Fuerza de Ataque X — «X Strike Force»).