Ubuntu logo

Packaging Guide

1. Introducción al desarrollo de Ubuntu

Ubuntu está formado por miles de componentes distintos, escritos en muchos lenguajes de programación diferentes. Cada componente, ya sea una biblioteca software, una herramienta o una aplicación gráfica, está disponible en forma de paquete fuente. Los paquetes fuente, en la mayoría de los casos, constan de dos partes: el código fuente en sí, y los metadatos. Los metadatos incluyen las dependencias del paquete, los derechos de autor e información sobre la licencia e instrucciones sobre cómo compilar el paquete. Una vez que el paquete está compilado, el proceso de construcción proporciona los paquetes binarios, que son los archivos .deb que el usuario puede instalar.

Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad’s build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror. Every day images are built for a selection of different Ubuntu flavours. They can be used in various circumstances. There are images you can put on a USB key, you can burn them on DVDs, you can use netboot images and there are images suitable for your phone and tablet. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the image. These images are then used for installation tests and provide the feedback for further release planning.

El desarrollo de Ubuntu depende en gran medida de la fase actual del ciclo de publicación. Se publica una nueva versión de Ubuntu cada seis meses, lo que solo es posible porque se han establecido fechas estrictas de congelación. Con cada fecha de congelación que se va alcanzando, los desarrolladores esperan hacer menos cambios y menos intrusivos. La congelación de funciones («feature freeze») es la primera gran fecha de congelación después de haber pasado la primera mitad del ciclo. En esta fase, las funciones deben estar ya prácticamente implementadas. El resto del ciclo se supone que se centrará en corregir errores. Después de que la interfaz de usuario, la documentación, el núcleo, etc. se congelan, se publica una versión beta que pasa gran cantidad de pruebas. De la versión beta en adelante, solo se corrigen errores críticos y se publica la versión candidata, la cual, si no contiene ningún problema serio, es la que se convierte en la versión definitiva.

./_images/cycle-items.png

Miles de los paquetes fuente, miles de millones de líneas de código, cientos de contribuyentes requieren de mucha comunicación y planificación para mantener altos estándares de calidad. Al principio y hacia la mitad de cada ciclo de emisión tiene lugar la «Ubuntu Developer Summit» (cumbre de desarrolladores de Ubuntu) en la que los desarrolladores y contribuyentes se juntan para planificar las características de las próximas versiones. Cada característica es discutida por sus accionistas y se escribe una especificación que contiene información detallada sobre sus supuestos, implementación, cambios necesarios en otras partes, cómo probarla y así sucesivamente. Todo esto se hace de forma abierta y transparente, así que puede participar remotamente y escuchar una transmisión de vídeo, chalar con los asistentes y suscribirse a cambios en las especificaciones, de forma que siempre esté al día.

Sin embargo, no todos los cambios pueden ser discutidos en una reunión, particularmente porque Ubuntu depende de cambios que se hacen en otros proyectos. Es por esto que los contribuyentes se mantienen en contacto permanente. La mayoría de los equipos o proyectos usan listas de correo dedicadas para evitar demasiado ruido no relacionado. Para una coordinación más inmediata, los desarrolladores y contribuyentes usan charlas en IRC («Internet Relay Chat»). Todas las discusiones son abiertas y públicas.

Otra herramienta importante relacionada con la comunicación son los informes de errores. Siempre que se encuentra un error en un paquete o en un parte de la infraestructura, se rellena un informe de error en Launchpad. Se recoge toda la información en dicho informe y se actualiza cuando sea necesario su importancia, estado y desarrollador asignado. Esto lo convierte en una herramienta efectiva para mantenerse al día de los errores de un paquete o proyecto y para organizar la carga de trabajo.

La mayoría del software disponible a través de Ubuntu no está escrito por los propios desarrolladores de Ubuntu. La mayoría está escrito por otros desarrolladores de otros proyectos de código abierto que luego son integrados en Ubuntu. Estos proyectos se denominan «upstreams» (aguas arriba), porque su código fuente fluye a Ubuntu, donde «simplemente» se integra. La relación con los proyectos «upstream» tiene una importancia crítica para Ubuntu. No es solo código lo que Ubuntu recoge aguas arriba, sino que los proyectos «upstream» obtienen también usuarios, informes de error y parches de Ubuntu (y de otras distribuciones).

El proyecto «upstream» más importante para Ubuntu es Debian. Debian es la distribución en la que se basa Ubuntu y muchas de las decisiones de diseño relativas a la infraestructura de empaquetado se hacen allí. Traicionalmente, Debian ha tenido siempre mantenedores dedicados para cada paquete individual o equipos dedicados de mantenimiento. En Ubuntu hay equipos que tienen interés en un subconjunto de paquetes también y, naturalmente, cada desarrollador tiene un área de especialización, pero la participación (y permisos de subida) está generalmente abierta a cualquiera que demuestre capacidad y voluntad.

Conseguir un cambio en Ubuntu como un nuevo contribuyente no es tan desalentador como parece y puede resultar una experiencia muy gratificante. No se trata únicamente de aprender algo nuevo y excitante, sino también de compartir la solución y resolver un problema para millones de otros usuarios.

Los desarrollos de código abierto se producen en un mundo distribuido con distintos objetivos diferentes y con áreas de interés diferentes. Por ejemplo, podría darse el caso de que alguien aguas arriba («upstream») esté interesado en trabajar en una nueva funcionalidad importante mientras que Ubuntu, debido a su estricta planificación de emisiones, está interesado en distribuir una versión sólida solo con algunas correcciones de errores. Es por ello que se usa el «desarrollo distribuido», en el que se trabaja en distintas ramas de código que son combinadas con las demás después de revisiones de código y suficientes discusiones.

./_images/cycle-branching.png

En el ejemplo mencionado anteriormente tendría sentido emitir Ubuntu con una versión existente del proyecto, añadir la corrección del error, integrarla aguas arriba («upstream») para su próxima emisión y distribuirla (si fuera conveniente) en la próxima emisión de Ubuntu. Sería el mejor compromiso posible y una situación en la que todo el mundo gana.

Para arreglar un error en Ubuntu, primero debería obtener el código fuente del paquete, después trabajar en la solución, documentarla de forma que sea fácil de entender por otros desarrolladores y usuarios y luego compilar el paquete para probarlo. Una vez lo haya probado, puede proponer fácilmente que el cambio se incluya en la publicación actualmente en desarrollo de Ubuntu. Un desarrollador con permisos para subir el código lo revisará y hará que se integre en Ubuntu.

./_images/cycle-process.png

Cuando intente encontrar una solución, habitualmente es una buena idea comprobar los proyectos aguas arriba («upstreams») para ver si el problema (o una posible solución) es conocido y, si no, hacer lo posible para que la solución sea un esfuerzo concertado.

Podrían ser necesarios pasos adicionales para hacer que el cambio se incluya en una versión antigua, aunque todavía soportada de Ubuntu, y enviarlo aguas arriba («upstream»).

Los requisitos más importantes para tener éxito en el desarrollo de Ubuntu son: tener una habilidad especial para «hacer que las cosas funcionen de nuevo», no tener miedo a leer documentación y a hacer preguntas, ser un jugador de equipo y disfrutar con algo de trabajo detectivesco.

Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on freenode.. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.