| Les deux révisions précédentesRévision précédente | |
| issue49:tutoubuntudev [2011/06/06 11:36] – auntiee | issue49:tutoubuntudev [2011/06/06 14:50] (Version actuelle) – andre_domenech |
|---|
| 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.** | 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. | 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. | 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. |
| 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.** | 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. | 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, le placer parmi les « Upstream » pour la version suivante et le fournir (s'il est prêt) dans la version suivante d'Ubuntu. Ce serait le meilleur compromis possible et une situation dans laquelle tout le monde gagne. | 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. | 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. |
