Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**Ubuntu is made up of thousands of different components, written in many different programming languages. Every component - be it a software library, a tool, or a graphical application - is available as a source package. Source packages in most cases consist of two parts: the actual source code, and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install.

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 the 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 CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu, and others, specify a list of required packages that get on the CD. These CD images are then used for installation tests, and provide the feedback for further release planning.**

Ubuntu est fait de milliers de composants différents, écrits dans de nombreux langages de programmation différents. Chaque composant, que ce soit une bibliothèque logicielle, un outil ou une application graphique, est disponible en tant que paquet source. Les paquets sources, pour la plupart, sont constitués de deux parties : le code source en lui-même et des méta-données. Ces méta-données incluent les dépendances du paquet, des informations de copyright et de licence, et des instructions pour construire (build) le paquet. Une fois que ce paquet source est compilé, le processus de construction produit des paquets binaires, qui sont les fichiers .deb que les utilisateurs peuvent installer.

Chaque fois qu'une nouvelle version d'une application sort ou que quelqu'un apporte un changement au code source qui entre dans Ubuntu, le paquet source doit être téléchargé vers les machines de « build » pour être compilé à nouveau. Les paquets binaires qui en résultent sont alors distribués vers l'archive et tous ses miroirs dans différents pays. Les URL dans /etc/apt/source.list pointent vers une archive ou un miroir. Chaque jour sont construites des images CD pour une sélection de différentes versions d'Ubuntu. Ubuntu Desktop, Ubuntu Server, Kubuntu et d'autres spécifient une liste des paquets requis sur chaque CD. Ces images CD sont ensuite utilisées pour des tests d'installation et fournissent un retour pour la prévision des futures sorties.

**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 possible only 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.

Thousands of source packages, billions of lines of code, and hundreds of contributors, require a lot of communication and planning to maintain high standards of quality. At the beginning 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 even if you cannot attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants, and subscribe to changes of specifications - so you are always up to date.**

Le développement d'Ubuntu est très dépendant de l'étape en cours dans le cycle de sortie. Une nouvelle version d'Ubuntu sort tous les six mois, ce qui n'est possible que parce qu'on a fixé des dates de gel très strictes. À chaque fois qu'une date de gel arrive, les développeurs doivent faire moins de modifications qui sont moins intrusives. Le gel des fonctionnalités est la première date de gel importante après que la moitié du cycle est passée. À cette étape, les fonctionnalités doivent être largement implémentées. Le reste du cycle est censé être centré sur la correction de bogues. Après cela, l'interface utilisateur, puis la documentation, le noyau, etc., sont gelés, puis une version bêta est livrée pour être soumise à de nombreux tests. À partir de cette version bêta, seul les bogues critiques sont réparés et une version candidate à la sortie est fabriquée ; si elle ne contient pas de problème sérieux, ce sera elle la version finale.

Des milliers de paquets sources, des milliards de lignes de code et des centaines de contributeurs, tout cela demande beaucoup de communication et de planification afin de maintenir un standard élevé de qualité. Au début de chaque cycle de sortie, se tient le Sommet des Développeurs Ubuntu où les développeurs et les contributeurs se réunissent pour planifier les fonctionnalités des prochaines sorties. Chaque fonctionnalité est discutée par ses parties prenantes et on rédige une spécification contenant des informations détaillées sur ses hypothèses, son implémentation, les changements nécessaires à d'autres endroits, comment la tester et ainsi de suite. Tout cela est fait d'une manière transparente et ouverte, de façon à ce que ceux qui ne peuvent pas assister à l'événement en personne puissent participer à distance et écouter un flux audio, discuter avec les participants et souscrire aux changements des spécifications, pour être toujours à jour.

**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 contributers use Internet Relay Chat (IRC). All discussions are open and public.

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.**

Cependant on ne peut pas discuter de chaque changement durant une réunion, en particulier parce qu'Ubuntu repose sur des changements qui seront apportés dans d'autres projets. C'est pourquoi ceux qui contribuent à Ubuntu restent constamment en contact. La plupart des équipes et des projets utilisent des listes de diffusion dédiées pour éviter trop de bruit de fond. Pour une coordination immédiate, les développeurs et les contributeurs utilisent des canaux IRC. Toutes les discussions sont ouvertes et publiques.

Les rapports de bogues sont un autre outil important concernant la communication. Lorsqu'un défaut est découvert dans un paquet ou un morceau de l'infrastructure, un rapport de bogue est rempli sur Launchpad. Toutes les informations sont collectées dans ce rapport et on met à jour si nécessaire son importance, son statut et la personne à qui elle est attribuée. Cela rend cet outil très efficace pour maîtriser les bogues dans un paquet ou un projet et organiser la charge de travail.

**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).

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.

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.**

La plupart des logiciels disponibles dans Ubuntu ne sont pas écrits par les développeurs Ubuntu eux-mêmes. La plupart sont écrits par des développeurs d'autres projets Open Source, puis sont intégrés dans Ubuntu. Ces projets sont appelés des « Upstream » (flux du dessus), car leur code source coule dans Ubuntu où on se contente de l'intégrer. La relation avec les « Upstream » est d'une importance critique dans Ubuntu. Il ne s'agit pas simplement de code qu'Ubuntu récupère depuis les « Upstream », mais c'est aussi les « Upstream » qui récupèrent des utilisateurs, des rapports de bogues et des correctifs depuis Ubuntu (et d'autres distributions).

Le plus important des « Upstream » pour Ubuntu est Debian. Debian est la distribution sur laquelle est basée Ubuntu et de nombreuses décisions de conception concernant l'infrastructure des paquets en proviennent. Traditionnellement, Debian a toujours eu des personnes dédiées pour la maintenance de chacun de ses paquets ou des équipes de maintenance dédiées. Dans Ubuntu, il y a aussi des équipes qui ont un intérêt pour un sous-ensemble de paquets et, bien entendu, chaque développeur a un domaine particulier d'expertise, mais la participation (et les droits de téléchargement montant) est en général ouverte à tous ceux qui montrent de l'habileté et de la volonté.

Apporter un changement à Ubuntu en tant que nouveau contributeur n'est pas si compliqué qu'il y paraît et peut être une expérience très gratifiante. Il ne s'agit pas seulement d'apprendre quelque chose de nouveau et d'excitant, mais aussi de partager une solution et de résoudre un problème pour des millions d'utilisateurs de par le monde.

**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 might be interested in working on a new big feature, while Ubuntu, because of the tight release schedule, might be 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.

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.

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.**

Le Développement Open Source se passe dans un monde distribué qui a différents buts et différentes zones d'intérêt. Par exemple, on peut imaginer le cas d'un « Upstream » particulier qui pourrait vouloir travailler sur une nouvelle fonctionnalité importante, tandis qu'Ubuntu, à cause de son calendrier de sortie serré, pourrait être intéressé par une version solide avec seulement une correction de bogue supplémentaire. C'est pourquoi nous faisons usage du « Développement distribué », dans lequel le code est retravaillé dans plusieurs branches qui sont ensuite fusionnées les unes avec les autres après les critiques et les discussions nécessaires.

Dans l'exemple précédent, cela aurait un sens de sortir Ubuntu avec la version actuelle du projet, d'ajouter la correction de bogue, la placer parmi les « Upstream » pour la version suivante et la fournir (si elle est prête) dans la version suivante d'Ubuntu. Ce serait le meilleur compromis possible et une situation dans laquelle tout le monde gagne.

Pour corriger un bogue dans Ubuntu, vous devez d'abord récupérer le code source du paquet, puis travailler pour le réparer, écrire une documentation pour que les autres développeurs et utilisateurs comprennent facilement ce que vous avez fait, puis construire un paquet pour le tester. Après l'avoir testé, vous pouvez facilement proposer que les changements soient intégrés dans la version d'Ubuntu en cours de développement. Un développeur qui a les droits de téléchargement montant vous renverra une critique puis l'intégrera dans Ubuntu.

**When trying to find a solution, it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already, and, if not, do your best to make the solution a concerted effort. Additional steps might involve getting the change backported to an older, still supported, version of Ubuntu, and forwarding it to Upstream.**

The most important requirements for success in Ubuntu development are having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player, and enjoying some detective work.

Good places to ask your questions are ubuntu-motu-mentors@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. 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.**

Lorsqu'on cherche une solution, c'est souvent une bonne idée de vérifier avec l'« Upstream » pour voir si le problème (ou une solution possible) est déjà connu et, si ce n'est pas le cas, de faire de votre mieux pour que la solution soit un effort concerté. Des étapes supplémentaires peuvent intégrer le fait de faire le changement sur une ancienne version d'Ubuntu encore supportée, puis de le faire suivre à l'« Upstream ».

Les prérequis les plus importants pour réussir dans le développement d'Ubuntu sont d'avoir le don de « faire fonctionner les choses  à nouveau », de ne pas craindre la lecture des documentations et de poser des questions, d'avoir un bon esprit d'équipe et d'aimer le travail de détective.

Voici quelques bons endroits pour poser vos questions : ubuntu-motu-mentors@lists.ubuntu.com et #ubuntu-motu sur irc.freenode.net. Vous trouverez facilement plein de nouveaux amis et des gens qui ont la même passion que vous : rendre le monde meilleur en fabriquant de meilleurs logiciels Open Source.