|
|
345.
|
|
|
Ubuntu's development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes. Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. The rest of the cycle is supposed to be focused on fixing bugs. After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release.
|
|
|
|
|
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.
|
|
Translated by
Ricardo Pérez López
|
|
Reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:27
|
|
|
346.
|
|
|
Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. At the beginning and in the middle of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. This is all done in an open and transparent fashion, so you can participate remotely and listen to a videocast, chat with attendants and subscribe to changes of specifications, so you are always up to date.
|
|
|
|
|
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.
|
|
Translated by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:42
|
|
|
347.
|
|
|
Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public.
|
|
|
|
|
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.
|
|
Translated by
Ricardo Pérez López
|
|
Reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:54
|
|
|
348.
|
|
|
Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload.
|
|
|
|
|
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.
|
|
Translated by
Ricardo Pérez López
|
|
Reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:61
|
|
|
349.
|
|
|
Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. These projects are called "Upstreams", because their source code flows into Ubuntu, where we "just" integrate it. The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions).
|
|
|
|
|
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).
|
|
Translated by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:68
|
|
|
350.
|
|
|
The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness.
|
|
|
|
|
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.
|
|
Translated by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:77
|
|
|
351.
|
|
|
Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there.
|
|
|
|
|
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.
|
|
Translated by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:86
|
|
|
352.
|
|
|
Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix. That is why we make use of "Distributed Development", where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion.
|
|
|
|
|
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.
|
|
Translated and reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:91
|
|
|
353.
|
|
|
In the example mentioned above it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins.
|
|
|
|
|
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.
|
|
Translated by
Jose Luis Tirado
|
|
Reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:101
|
|
|
354.
|
|
|
To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu.
|
|
|
|
|
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.
|
|
Translated by
Ricardo Pérez López
|
|
Reviewed by
Jose Luis Tirado
|
|
|
|
Located in
../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:106
|
