FacebookGoogle+TwitterLinkedIn
Cet article est ma traduction en français d’un billet que Mark Shuttleworth à publié en anglais sur son blog le 15 mai 2007.

Il y a eu une vague de discussions autour de l’idée de synchronicité dans les projets de logiciels libres. J’aimerais donner une vision plus globale, mais je suis à Prague en train de préparer le FOSSCamp et l’Ubuntu Developer Summit (je suis impatient de retrouver tout le monde !) ce qui fait que je ne livrerais que quelques réflexions et des réponses à des commentaires que j’ai vu.

Robert Knight a résumé les arguments que j’ai donné l’année dernière lors d’une présentation à l’aKademy. J’ai vraiment été ravi par l’annonce récente que les principales conférences annuelles des développeurs de GNOME et de KDE (GUADEC et aKademy) se dérouleront en 2009, au même moment et au même endroit. C’est un pas en avant important vers une collaboration encore meilleure. Des initiatives comme FreeDesktop.org ont été très utiles ces dernières années et la venue d’une conférence partagée accélérera la mise en avant des meilleures idées au sein des deux projets. Réunir tous les développeurs passionnés et dévoués de ces deux projets dans un même espace physique aura des retombés positives pour chacun des deux projets.

Aaron Seigo de KDE Plasma a opté pour une position résolument contre les cycles de versions synchronisés et ses trois articles récents sur le sujet sont intéressants à lire.

Aaron parle de problèmes à propos de fonctionnalités qui seront « bâclées » à la sortie d’une version pour rester dans le cycle. Il est tout a fait vrai que la discipline vis-à-vis de « ce qui est distribué » est essentielle pour permettre de s’engager sur des versions. Il est malheureux que des fonctionnalités ne soient pas toujours prêtes au moment où elles étaient prévues. Mais cela vaut la peine de réfléchir un peu à l’importance que représentent des fonctions spécifiques par rapport à une version complète. Lorsqu’une version arrive dans les temps, cela donne confiance dans le projet et cela déclenche une série de nouveaux tests, de la publicité, de l’enthousiasme et bien sûr des rapports de bogues. Le code neuf donne un coup de fouet et au final améliore. Les projets de logiciels libres ne sont pas comme les projets propriétaires – ils ne sont pas obligés de publier de nouvelles versions pour générer des revenus provenant de nouvelles licences et de mises à jours. Nous pouvons choisir de laisser passer une fonction particulière pour bénéficier d’une nouvelle phase de tests et de retours sur tout le code qui la compose.

Certains développeurs sont passionnés par des fonctions spécifiques, d’autres sont passionnés par le projet dans son ensemble. Il y a deux technologies spécifiques, ou plutôt méthodologies, qui ont énormément aidé à les séparer tout en leur donnant plus de force. Ce sont les systèmes de gestion de versions (Version Control System ou VCS) et le développement piloté par les tests (Test Driven Development ou TDD).

Nous avons découvert que les développeurs qui sont vraiment concentrés sur une fonction spécifique ont tendance à travailler sur cette fonction dans une branche (ou un ensemble de branches qui collaborent), en l’améliorant « jusqu’à ce que ça soit fini » sans ce préoccuper du cycle de version du projet. Ensuite ils fournissent la fonction dans son intégralité, généralement après avoir fait des tests. Ceci nécessite bien sûr de disposer d’un VCS qui sache très bien gérer la création de branches et la fusion. Vous devez pouvoir fusionner en permanence à partir du tronc principal, de sorte que la branche de votre fonction puisse toujours être fusionné *derrière* le tronc principal. Vous devez aussi pouvoir fusionner ce que font plusieurs développeurs qui travaillent tous sur les mêmes fonctionnalités. Bien entendu, Bazaar reste ma préférence réaffirmée en matière de VCS, car les développeurs ont pensé avec un très grand soin la façon de gérer la collaboration d’équipes sur différentes plates-formes, projets et flux de travail, mais n’importe quel VCS, même centralisé, peut convenir s’il gère bien les branches.

D’un autre côté, une suite de test complète vous permet d’être plus ouvert à de gros changements dans le tronc principal, car vous savez que les tests protègent la fonctionnalité dont disposaient les gens *avant* le lancement. Une suite de test est comme un champ de forces, protégeant l’intégrité du code dont on connaît le comportement, face à des changements constants. La plupart des projets que je finance ont adopté une approche de test avant lancement, dans lequel les lancements sont gérés par un robot qui refuse de valider le lancement tant que tous les tests n’ont pas été passés. Vous ne pouvez pas discuter avec un robot ! La beauté de tout ceci est que votre tronc principal est « toujours prêt à devenir une version ». En fait ce n’est pas *totalement* vrai, car vous voulez toujours faire un peu plus de contrôle qualité (QA) avant de laisser partir les bits, mais vous avez la merveilleuse assurance que la suite de test passera toujours. Toujours.

Donc, les VCS qui gèrent bien les branches et le développement piloté par les tests font toute la différence. Travaillez sur votre fonction jusqu’à ce qu’elle soit finie, puis intégrez la au tronc principal quand la phase est propice. Pour ceux qui tiennent compte de la version, la phase de gel de fonctionnalités est peut être plus étroite si vous avez de super tests.

Il y a beaucoup de discussions concernant la durée exacte d’un cycle « optimal », avec des commentaires au sujet des phases de développement, de gel de fonctionnalités, de contrôle qualité et le reste. Je pense que c’est un peu noyer le poisson, quand vous utilisez un système qui gère bien les branches, car le développement de fonctionnalités ne s’arrête absolument pas lorsque le tronc principal est gelé en vue d’une version. Ceux qui préfèrent continuer à fixer leur branches le font, en se préoccupant de ce qui les intéresse le plus.

Pourtant, je continue de penser que les durées des cycles sont importantes. Aaron spécule sur le fait qu’un cycle de 4 mois pourrait convenir pour un site Web. Je suis d’accord, et dans le cas de Launchpad, après quelques variations sur le thème, nous sommes allé vers un cycle de 4 mois. La principale différence pour moi est que l’on a un seul point de déploiement du code en question, ce qui fait que l’on a pas à se préoccuper plus que ça de la compatibilité entre les mises à jour et les différentes versions. L’équipe de Launchpad à un système génial, d’où ils sortent chaque jour, du code frais provenant du tronc principal qu’ils envoient sur un ensemble de serveurs applicatifs (appelé « edge.launchpad.net »), que les bêta testeurs de LP utilisent par défaut. Une fois par mois, ils en sortent une nouvelle mouture qui est placée sur tous les serveurs d’application, de même lorsqu’ils révisent la base de données et peuvent introduire un nombre substantiel de nouvelles fonctionnalités. C’est serré, mais cela donne beaucoup de rythme au projet. Et nous planifions par « périodes de 4 mois », au moins, le passage au cycle suivant. La dernière planification était de 9 mois, ce qui fut bien trop long.

Je pense que l’idée de cycles dans les cycles est super. Aaron explique que 6 mois est trop long pour des sorties fréquentes, et trop court pour pouvoir éviter de mettre à l’écart des fonctionnalités en les repoussant d’un cycle à l’autre. J’ai déjà dit que la volonté de rejeter une fonctionnalité qui n’est pas prête est une force plutôt qu’une faiblesse. Ce serait intéressant de voir si l’équipe de Plasma a adopté un cycle « interne » plus court, par exemple de 2 ou 3 mois, et si elle le fait tenir dans un cycle « externe » de 6 mois, en supposant que les problèmes d’Aaron aient été pris en compte.

Pour des projets importants, le fait que tout tourne autour d’une année s’avère être très important. Vous voulez vraiment un cycle qui se divise précisément en année, car beaucoup d’évènements externes se produisent sur cette base. Et vous voulez une certaine cohésion entre les parties. Chez Canonical, nous avions l’habitude de faire des points en suivant des cycles de 4 mois (3 fois par an) et d’avoir un cycle de 6 mois (deux fois par an) pour les versions d’Ubuntu, ce qui était excessivement complexe. Dès que nous nous sommes suffisamment connus les uns les autres, nous n’avons plus eu besoin de nous réunir tous les 4 mois, nous avons alors aligné les deux cycles et depuis tout est bien plus fluide.

Certaines personnes ont le sentiment que les distributions ne sont pas un facteur important dans le choix d’un cycle de version pour les projets en amont. Et d’une certaine manière c’est vrai. Il y aura toujours une « prochaine » version ou une autre distribution qui retiendra votre attention, et heureusement, une version d’un projet en amont qui rate « cette » version sera dans la suivante. Mais je pense que cela vous privera du bénéfice d’avoir mis au plus tôt votre travail à disposition d’un public plus large. Il existe une grande méthodologie de gestion de projet appelée « lean », qui fonctionne comme cela. Et elle dit que lorsque vous travaillez sur un produit, le temps passé à attendre que quelqu’un d’autre ait fait quelque chose, est « gaspillé ». Vous pourriez avoir fait ce travail plus tard, et fait quelque chose d’autre avant qui aurait généré des résultats plus tôt. Tout ceci est basé sur les résultats étonnants provenant des vrais chaînes de production, telles que celles des voitures et de l’électronique.

Donc, bien qu’il soit certainement vrai que vous puissiez sortir une version qui rate la « vague », mais qui attrape la seconde vague dans les six mois, vous êtes en situation de rater tous les rapports de bogues, les correctifs, et les autres opportunités d’enseignement et d’amélioration qui auraient pu arriver si vous aviez été sur la première vague. Il n’y a rien de moralement mauvais dans tout ça, et il y a probablement des choses plus importantes, mais néanmoins, cela vaut la peine d’y penser.
Certaines personnes ont dit que mon intérêt dans ce domaine était « pour Canonical », ou « juste pour Ubuntu ». Et ce n’est pas vrai du tout. Je pense que c’est une approche plus productive pour tout l’écosystème du logiciel libre, et que cela nous aidera à rivaliser avec le monde propriétaire. C’est bon pour tout le monde. Et il n’y à pas qu’Ubuntu qui fasse des versions régulières tous les 6 mois, Fedora a adopté le même cycle, ce qui est formidable car cela augmente les opportunités de collaboration entre les deux distributions – nous avons plus de chances d’avoir les mêmes versions de composants clés à un moment donné.

Aaron dit :

Supposons que le projet A dépende de B, et que B sorte en même temps que A. Cela signifie que A va se retrouver un cycle derrière B en utilisant ce que B fourni, ou devra suivre vraiment de très près la fin du cycle de B pour pouvoir se servir de ce qu’il produit. Ce que vous souhaitez réellement est une approche décalée où B sort au moment ou A commence à travailler sur des choses.

Ceci va bien sûr complètement à l’encontre de la doctrine que prêche Mark, « tout le monde le même mois, tous les 6 mois ».

Je n’ai jamais suggéré que *tout le monde* devait sortir une version en même temps. En fait, pour Ubuntu nous avons convergé vers l’idée de faire une version environ un mois *après* celle de notre plus gros projet en amont prévisible, qui se trouve être GNOME. Et de manière similaire, le fait que le noyau ait un cycle relativement prévisible est très utile. Nous ne sortons bien sûr pas une version d’Ubuntu le même jour que la sortie du noyau, mais nous sommes capables de prévoir et de communiquer efficacement avec les gens de kernel.org concernant les versions autour desquelles nous avons de bonnes raisons de collaborer.

Plutôt que d’essayer et de sortir tout d’un seul coup, je trouve sensé de décaler les sorties en se calant grossièrement sur leurs dépendances.

Pour être bien clair, je ne demande pas aux projets que je vais mentionner ci-dessous de changer quoi que ce soit, je donne une image ou un scénario pour les besoins de la discussion. Chaque projet devrait trouver son propre rythme et se concentrer sur ce qui l’intéresse le plus. Je pense qu’il y d’importants bénéfices à tirer de la synchronicité, donc j’esquisse un scénario.

Imaginons que notre but soit d’avoir trois vagues de versions, espacées d’un mois.

Dans la première vague, nous avons le noyau, la chaîne d’outils, les langages et les bibliothèques système, et peut-être des composants critiques pour la performance – et la sécurité -. Linux, GCC, Python, Java, Apache, Tomcat, … sont des éléments qui nécessitent probablement le plus de stabilisation et de test avant d’être livrés à l’innocent, et ce sont aussi des éléments qui doivent être relativement statiques de sorte que d’autres éléments puissent aussi se stabiliser. Je pourrais aussi inclure là-dedans des choses comme Gtk.

Dans la seconde vague, nous avons des applications, les environnements de bureau et d’autres utilitaires. AbiWord et Koffice, Gnumeric et peut-être même Firefox (bien que certains pourraient dire que Firefox est un noyau et un gestionnaire de fenêtres … ;-)).

Et dans la troisième vague, nous avons les distributions – Ubuntu, Fedora, Gentoo, peut-être Debian et OpenSolaris. Le but serait d’encourager aussi plus de collaboration et de réflexion autour des versions de composants qui se trouvent dans les distributions, de sorte qu’elles puissent effectivement échanger des informations, des correctifs et des rapports de bogues.

J’ai vraiment un sentiment fort et persistant qu’il y aura plus d’intérêt pour les projets qui livreront leur code à un public plus large que pour ceux qui vérifieront leur VCS du jour, le tiendront à jour et le généreront. Et les distributions sont la meilleur façon de voir votre code … distribué ! Par conséquent, le fait que Fedora et Ubuntu aient convergé vers le même rythme est de très bon augure pour les projets en amont qui pourront ainsi bénéficier des tests plus nombreux, plus récurrents, très peu de temps après leur sortie. Je sais que chaque projet fera ce qui lui convient, et j’espère que cela leur conviendra aussi de pouvoir livrer leur code plus rapidement sur les serveurs et les ordinateurs de bureau de sorte que les correctifs puissent également arriver plus vite.

En prenant du recul sur la vision à six mois, il est clair qu’il y a un rythme de sortie plus lent des versions « entreprise », « LTS » ou « majeures ». Ce sont celles que les gens prennent en charge pendant des années et des années. Ce sont aussi celles pour lesquelles les vendeurs de matériel veulent le plus souvent écrire des gestionnaires de périphériques. Et un gros problème pour eux est encore « quelle version de X, du noyau, de libC, de GCC, etc. devrons-nous prendre en charge ? » Si les distributions peuvent s’articuler, à la fois avec les projets en amont et le reste de l’écosystème, j’ai toutes les raisons de croire qu’avec une information claire les gens répondront que cela leur convient. J’ai parlé avec des développeurs du noyau qui ont dit qu’ils ADORERAIENT savoir quelle version du noyau va tourner dans RHEL ou une version LTS d’Ubuntu, parce que cela leur permettrait de prévoir leur travail en conséquence. Donc faisons-le !

Enfin, dans les commentaires sur les observations pertinentes de Russell Coker il y a une suggestion que j’aime beaucoup – c’est que les dates des phases de gel de fonctionnalités plus que les dates coordonnées pourraient faire la différence. Différentes distributions ont des points de vue différents sur la manière d’intégrer, de tester et de déployer du nouveau code, et fixer les dates de sortie suggère une réduction dans la flexibilité qu’elles pourraient avoir pour se positionner différemment. Je pense que c’est un point important. Je me suis initialement concentré sur la création d’un élan dans la communauté du logiciel libre, et encouragé davantage la collaboration. Si une version LTS d’Ubuntu, et une version de Debian, et une version de RHEL, utilisaient la même version majeure du noyau, de GCC et de X, nous pourrions améliorer grandement TOUTE la prise en charge des matériels actuels. Elles ne sortiraient pas à la même date, mais elles seraient toutes bien meilleures que si elles sortaient indépendamment. Et l’écosystème tout entier considérerait qu’un investissement dans du code ciblant ces versions clés se justifierait plus facilement.

Origine : Discussing free software synchronicity