Des cycles de six mois sont parfaits. Parlons maintenant des méta-cycles : des cycles de version plus longs pour des travaux majeurs. Je suis très intéressé par un échange entre communautés sur ce sujet, je vais donc esquisser quelques idées et encourager les personnes d’autant de communautés du Logiciel Libre que possible a déposer leur commentaires ici. Je résumerais ces commentaires dans un billet ultérieur, qui sera sans nul doute bien plus réfléchi et pertinent que celui-ci :-)

Avant-propos : baser la cadence sur les bonnes pratiques

La pratique des versions régulières, et maintenant des versions à intervalles de temps réguliers, devient courante dans la communauté du Logiciel Libre. Du noyau, à GNOME et KDE, à X, et à des distributions comme Ubuntu, et Fedora, l’idée d’un cycle régulier et prévisible est maintenant mieux compris et plus largement adopté. Plusieurs personnes plus intelligentes que moi ont présenté les bénéfices d’une telle cadence : dynamiser la communauté toute entière, publier VRAIMENT plus tôt et plus souvent, mélanger le bon et le mauvais code, phase de correction rapide.

Il y a eu quelques expériences avec différents cycles. Je suis impliqué dans des projets qui ont des cycles de 1 mois, 3 mois et 6 mois, pour différentes raisons. Ils fonctionnent tous bien.

… mais concernant les besoins du long terme

Mais il y a aussi des défauts dans le cycle de six mois :

• il est difficile d’expliquer à vos utilisateurs que vous avez fait des modifications définitives et significatives ;
• il est difficile de savoir pour combien de temps il faut assurer du support, vous ne pouvez évidemment pas supporter chaque version indéfiniment.

Je pense qu’il y a un consensus grandissant sur ce point, des deux côtés du débat sur la « cadence » originelle?

L’histoire de deux philosophies, avec peut-être une théorie unificatrice

Il y a quelques années, à l’AKademy de Glasgow, j’étais au centre d’un grand débat sur les cycles de six mois. J’étais un fervent défenseur du cycle de six mois, et j’étais intéressé par les arguments contradictoires. Le plus fort de ces arguments concernait la faisabilité de « changements importants ».

Le refrain habituel était que « Il y a des choses que l’on ne peut tout simplement pas faire en six mois ». « On doit pouvoir prendre plus de distance, et il faut planifier les grands changements ». GNOME a beaucoup été critiqué pour avoir « stagné » à cause de son incapacité à faire des choix judicieux dans un cycle de six mois (et avec les perpétuelles garanties de rétro-compatibilité). De telles discussions deviennent souvent idéologiques, avec d’un côté certaines personnes qui disent que « On peut tout faire évoluer de façon incrémentale » et d’autres qui disent que « Il faut faire une rupture nette ».

À l’époque, KDE se préparait pour KDE 4.0, une initiative importante et courageuse s’il en est. Et GNOME semblait heureux de produire ses versions régulières. Lorsque la version de KDE est arrivée, elle était belle, mais elle avait a de vrais problèmes. Comme on pouvait s’y attendre, les partisans des versions régulières déclarèrent « regardez, nous vous l’avions dit, les GROSSES versions ne marchent pas ». Mais depuis, KDE a cessé de faire des améliorations régulières, bien cadrées et incrémentales, et KDE est superbe. Les avantages de ce geste audacieux apparaissent maintenant clairement. Bien joué KDE :-)

De son côté, GNOME est maintenant plus conscient des limites des versions régulières. Je suis très excité par l’enthousiasme et l’esprit avec lequel la campagne « l’expérience utilisateur COMPTE » est reprise dans Gnome, il y a une réelle volonté d’offrir des changements révolutionnaires. Cela a commencé l’an dernier lors de la réunion au sommet de Gnome sur l’ergonomie, que j’ai apprécié et à laquelle ont participé quelques membres des équipes de Canonical en charge de l’ergonomie et du design, et les fruits de cette évolution des tendances se profilent dans des choses comme le nouvel environnement Activités.

Il est maintenant clair qu’un changement comme celui-ci représente une rupture définitive avec le passé et qu’il prendra plus qu’une version conçue en six mois pour arriver à maturité. Et plus important que tout, il s’agit d’une occasion de faire d’autres modifications significatives et rompant avec le passé. Une rupture avec le passé. Un geste audacieux. Et il y a donc eu une série de conversations sur la façon de « faire une 3.0 », en clair, comment rompre avec la tradition du changement progressif, afin de rendre cette vision possible.

Il me semble que les deux projets convergent vers un ensemble commun d’idées :

• Les versions rapides et prévisibles sont parfaites pour maintenir la motivation et faire évoluer le code de manière propre et efficace, elles évitent d’aller à l’échec, elles consolident les choses et permettent de laisser murir les bonnes et les mauvaises idées de manière coordonnée et gérée.
• Les grandes versions sont énergisantes. Elles sont motivantes, elles donnent aux gens le sentiment qu’il est possible de changer quelque chose, elles libèrent beaucoup d’énergie créative et génèrent de nombreuses et saines discussions. Mais elles peuvent être un peu brouillon, des choses peuvent se casser en route, et c’est une bonne chose.

De façon anecdotique, il y a d’autres histoires intéressantes qui se nourrissent de tout cela.

La communauté Python a récemment décidé que Python 3.0 aurait un cycle plus court que les versions habituelles de Python. La version 3.0 sert à secouer les idées et le code pour les versions 3.x, mais elles ne sera pas adoptée massivement ce qui fait que cela n’a pas vraiment de sens de faire beaucoup d’effort pour la maintenir – on la sort, avec un cycle court, et on investit ensuite dans la qualité durant le cycle suivant parce que la version 3.x sera beaucoup plus utilisée que la 3.0. Cela me rappelle beaucoup KDE 4.0.

Je suis donc intéressé par les opinions, les défis, les idées, les engagements, les hypothèses, etc. à propos de l’idée des méta-cycles et comment nous pourrions nous organiser pour en tirer avantage le plus possible. Je crois que nous pouvons définir une bonne pratique, qui inclut des versions régulières pour une amélioration continue suivant un calendrier prévisible, et AUSSI définir une bonne pratique pour savoir comment les version MAJEURES se situent dans cette cadence, de manière très structurée et gérable. Je pense que nous pouvons tirer profit des expériences de GNOME et KDE, et d’autres projets, pour construire cette réflexion.

C’est également important pour les distributions

Les principales distributions ont tendance à avoir des versions importantes, aussi bien que des versions fréquentes. RHEL a Fedora, Ubuntu fait des versions LTS, Debian suit le rythme de sa logique d’intégration continue à l’extrême avec Sid et Testing :-) .

Lorsque nous avons fait Ubuntu 6.06 LTS nous disions que nous en ferions une autre dans « 2 ou 3 ans ». Quand nous avons fait la 8.04 LTS nous disions que les bénéfices de la prédictibilité d’une LTS sont tels qu’il serait bien de dire à l’avance quand serait la prochaine LTS. Je disais que j’aimerais que ça soit la 10.04 LTS, un cycle majeur de 2 ans, à moins que nous ayons la possibilité de coordonner les versions majeures avec une ou deux autres des principales distributions – Debian, Suse ou Red Hat.

J’ai parlé avec des gens de chez Novell, et il ne semble pas qu’il y ait de possibilité de se synchroniser pour l’instant. En discutant avec Steve McIntyre, le leader du projet Debian, nous avons repéré une possibilité de collaboration intéressante. Debian vise un cycle de 18 mois, qui amènerait leur prochaine version en octobre 2010, ce qui correspondrait avec la sortie de la version Ubuntu 10.10. Nous pourrions donc retarder la LTS d’Ubuntu jusqu’en octobre 2010, en nous synchronisant et en collaborant avec le projet Debian pour avoir des versions très proches en termes de choix d’infrastructure. Cela faciliterait grandement le partage des correctifs, un plus pour tout le monde. Puisqu’il y aura beaucoup de gens d’Ubuntu à la Debconf, et espérons un grand nombre de développeurs Debian à l’UDS de Barcelone en mai, nous aurons des chances d’examiner cette possibilité en détail. Si cette idée reçoit un accueil favorable, plait et suscite beaucoup d’implication chez Debian, je serais prêt à promouvoir l’idée de faire passer la LTS de 10.04 en 10.10 LTS.

Questions et options

Alors, quelles pourraient être les « bonnes pratiques » d’un méta-cycle ? Quelles sortes de choses devraient être prises en compte dans la planification de ces méta-cycles ? Quels problèmes entraîneraient-t-elles, et comment ceux-ci seraient-ils le mieux traités ? Comment les cycles courts (3 mois, 6 mois) se situent-ils dans un méta-cycle plus large ? Poser ces questions à de nombreuses communautés aidera à tester les idées et à retenir les meilleures d’entre-elles.

Quel nom conviendrait bien à ce type de méta-cycle ? Méta-cycle fait … très méta.

Il est vrai que la “première version d’un cycle majeur” (KDE 4.0, Python 3.0) est mieux faite dans la mesure où un cycle court n’empiète pas sur l’attention à porter au long terme ? Y a-t-il des contre-exemples, ou de meilleurs exemples, de ceci ?

Quelle version dans un cycle majeur est-elle la plus indiquée pour le support à long terme ? Est-ce la dernière des versions avant que de nouveaux changements important surviennent (Python 2.6 ? GNOME 2.28 ?) ou est-ce le résultat de quelques itérations rapides sur la versions X.0 (KDE 4.2 ? GNOME 3.2 ?) Est-ce important ? Je crois qu’il y a avantage pour les projets en amont à supporter occasionnellement une version pendant une période plus longue que d’habitude, parce que c’est ce que les grandes sociétés souhaitent.

Est-ce qu’un cycle d’une année complète serait bénéfique ? Est-ce que par exemple 2 ans et demi serait une bonne idée ? Personnellement, je ne pense pas. Je pense que les conférences et les vacances ont tendance à se passer au même moment chaque année et c’est bien plus facile de raisonner en termes de cycles d’années complètes. Mais au cours de discussions informelles à ce propos, certains ont dit que 18 mois, d’autres que 30 mois (2 ans et demi), pourrait leur convenir. Je pense qu’ils sont diiiingues, qu’en pensez-vous ?

Si ce n’est pas 2 ou 3 ans, qu’est-ce qui vous conviendrait le mieux ? Du côté matériel les gens ont tendance à dire « 2 ans ! » pour bénéficier plus tôt des nouveaux matériels. Pour ce qui est du logiciel ils disent « 3 ans ! » pour avoir  moins de changements à gérer. Personnellement, je suis dans le camp des 2 ans, mais je pense qu’il est plus important de s’aligner sur le rythme de la communauté, et si GNOME, KDE ou le noyau voulaient 3 ans, je serais partant.

Comment les méta-cycles de différents projets cohabitent ? Cela a-t-il un sens d’avoir des choses de bas-niveau relatives au matériel sur un cycle différent que d’autres de haut-niveau visibles par l’utilisateur ? Ou bien cela a-t-il plus de sens d’avoir un rythme de vie commun de haut en bas ?

Cela aurait-il plus de sens d’étaler les versions à long terme en fonction de leur dépendance à une autre, comme GCC puis X et OpenOffice ? Ou bien cela aurait-il plus de sens de leur faire suivre à toutes le même méta-cycle, afin que nous ayons par moment des changements radicaux, et à d’autres beaucoup de stabilité ?

Y a-t-il des projets qui fonctionnent déjà comme cela ?

Y a-t-il des théories ou des pratiques établies dans ce domaine ?

Une discussion entre communautés

Si vous avez lu jusqu’ici, merci ! Veuillez commenter, et si vous êtes intéressé alors veuillez remonter ces questions dans les communautés dont vous vous occupez, et rapportez les résultats de ces discussions ici sous forme de commentaires. Je suis quasiment sûr que nous pouvons faire évoluer l’art du logiciel à un niveau supérieur si nous pouvons tirer parti du fait que nous ne sommes PAS propriétaires, et c’est une des clés pour y parvenir.

Origine : Meta-cycles: 2-3 year major cycles for free software? (http://www.markshuttleworth.com/archives/288)