En retournant sur son blog (
http://www.markshuttleworth.com), j'ai vu qu'il y avait un nouveau billet pour parler des cycles pour ubuntu et le monde du libre. J'ai trouvé ça très intéressant et je n'ai pas vu de sujets qui en parlait donc j'ai choisi de traduire cette lettre pour pouvoir en discuter.
Je préviens quand même que je n'ai pas eu envi de me prendre la tête pendant 107 ans sur la traduction. J'ai simplement voulu que ce soit compréhensible sans faire de traduction au mot à mot. Vu qu'à lire, c'était rapide, mais à traduire, c'était quand même assez long, j'ai zappé mes réflexes de launchpad ou autres par un: "Je vais pas y passer la nuit, c'est intéressant mais c'est pas du Zola non plus donc je vais aller au plus simple". Donc vous voilà prévenu; il doit rester de nombreuses fautes d'orthographe, quelques petites erreurs mais ça reste très compréhensible et je pense sans contresens, et j'ai mis quelques NDT pour note du traducteur en cas de doute plutôt que me prendre la tête. 😃
________________________________________________________________________________________________
Meta-cycles: 2-3 ans par sortie majeure pour les logiciels libres?
Un cycle de six mois est génial.
Maintenant parlons des méta-cycles: les cycles des versions améliorées pour les travaux majeurs. Je suis très intéressé par une discussion inter-communautaire sur ce sujet, et mettrais en avant certaines idées et encourage les gens de toutes les communautés possibles du logiciel libre à laisser leur commentaire ici. Je résumerais ces commentaires dans un futur billet, qui sera sans doute beaucoup plus sage et complet que celui-ci 🙂
Le fond: sortir de nouvelles versions avec la meilleure cadence possible
La pratique de nouvelles versions régulières, et maintenant de versions planifiées, est devenue répandue dans le monde du logiciel libre. Du noyau, à gnome et kde, à x, et des distributions comme Ubuntu, Fedora, l'idée d'un cycle régulier, prévisible est maintenant mieux comprise et acceptée. Beaucoup de personnes plus futé que moi se sont agencés autour des bénéfices d'une telle cadence: énergiser la commnunauté, RÉELLEMENT sortir une nouvelle version tôt et souvent, permettre de séparer le bon et le mauvais code, des moyens rapides de correction.
Il y a eu divers expérimentations avec différents cycles. Je suis impliqué dans des projets de 1 mois, 3 mois et 6 mois. Ils fonctionnent tous très bien.
... mais révèlent aussi certains besoins d'une version à long terme
Mais il y aussi certaines faiblesses dans un cycle de six mois:
-> Il est difficile de communiquer à vos utilisateurs sur certains changements définitifs ou significatifs.
-> Il est difficile de savoir quoi supporter et pour combien de temps, on ne peut pas objectivement maintenir chaque version indéfiniment.
Je pense que certaines idées s'enrichissent dans tout celà, des deux côtés du débat original sur la cadence.
Un conte sur deux philosophies, avec peut-être une théorie unificatrice
Quelques années plus tôt, à l'académie de Glasgow, j'étais dans une grande discussion sur le cycle de six mois. J'étais un fervent défenseur de cette cadence de six mois, et intéressé par les arguments contre. Le plus fort d'entre eux était le défi de faire de "gros changements audacieux".
"On ne peut tout simplement rien faire en six mois" était le refrain habituel. "On doit pouvoir être capable de prendre du recul, et un plan est nécessaire pour de grandes modifications". Il a y eu de nombreuses critiques de GNOME pour avoir "stagné" dû à l'impossibilité de faire des choix pertinents dans un cycle de six mois (et avec de perpétuels retour en arrière sur la compatibilité garantis). De telles discussions deviennent souvent idéologiques, avec ceux d'un coté disant "on peut faire évoluer n'importe quoi par incrémentation" et les autres disant "une pause pour nettoyer est obligatoire".
Avec le temps, KDE s'est préparé à passer à KDE 4.0, un changement significatif et audacieux. Et GNOME était presque heureux de faire ses mises à jours régulières. Quand la version de KDE est arrivé, elle était magnifique, mais avait aussi de gros problèmes. Bien entendu, les partisans d'un cycle régulier dirent "vous voyez, on vous l'avait dit, les GROSSES mises à jour ne fonctionnent pas". Mais depuis KDE a changé pour des cycles réguliers, bien préparé, avec des améliorations incrémentielles, et KDE est visuellement magnifique. Soudain, ce gros changement audacieux a attiré l'attention, et les bénéfices sont devenus clairs. Bien joué KDE. 🙂
De l'autre côté de la barrière, GNOME est beaucoup plus conscient des limitations des versions régulières. Je suis très enthousiasmé par le piquant et l'esprit du slogan "L' expérience de l'utilisateur COMPTE" prise par GNOME, il y a un réel désir de modifications innovantes. Celà est apparu à l'excellent Gnome Usability Summit (NDT: Sommet pour l'utilisation de gnome) l'année dernière, que j'ai apprécié et à laquelle de nombreuses personnes chez Canonical travaillant sur l'utilisation et le design ont participé, et celà a porté ses fruits comme avec par exemple le nouveau module de notifications (NDT: pas sûr de mon coup là dessus, c'est peut être autre chose)
Mais il est devenu clair qu'un changement comme celà représente une cassure radicale avec le passé, et prendra sans doute plus d'une version de six mois pour être achevé. Et le plus important, que c'est une opportunité pour faire d'autres modifications signicatives et particulières. Une coupure avec le passé. Un grand changement audacieux.Et donc il y a eu de nombreuses discussions sur: "Comment créer une version 3.0 ?", en pratique, comment sortir de la tradition de modifications incrémentielles, pour rendre cette vision bien réelle.
Ce qui m'a frappé était que les deux projets commençaient à converger vers un socle commun d'idées:
>> Rapide, les sorties prévisibles sont super pour garder la motivation à un haut niveau et faire évoluer le code proprement et efficacement, elles sortent les gens d'une ambiance proche de la marche funèbre, permettent de garder les choses au coeur de l'attention et de séparer les bonnes et mauvaises idées d'une façon organisée et coordonnée.
>> Les grosses versions sont énergisantes également. Elles sont motivantes, elles permettent aux gens de penser que l'on peut tout changer, elles permettent une énergie créatrice énorme et génère de nombreuses et saines discussions. Mais elles peuvent aussi devenir désordonnées, s'arrêter en cours de routes, ce qui est aussi quelque chose de sain.
Anecdotiquement, il y d'autres histoires intéressantes qui rejoignent le sujet.
Récemment, la communauté Python a décidé que Python 3.0 fonctionnerait sur un cycle plus court que le cycle habituel de python. La version 3.0 est là pour confronter les idées et le code pour une 3.x, mais ne sera pas réellement adopté elle-même donc celà n'aurait pas grand sens de mettre énormément d'efforts pour la maintenir - sortir tout ça, adopter un cycle court, et ensuite miser sur la qualité pour le prochain cycle car la 3.x sera beaucoup plus utilisé que la 3.0. Celà me rappelle beaucoup KDE 4.0.
Donc, je suis intéressé par toutes les opinions, défis, idées, tentatives, hypothèses etc sur l'idée des méta-cycles et comment nous pourrions nous organiser pour en tirer le meilleurs profit. Je soupçonne que nous puissions définir un meilleur usage, qui comprendrait des versions régulières pour une amélioration continue définie sur un calendrier, et AUSSI définir une pratique sur la façon dont les versions MAJEURES s'intègrent à ce rythme, dans une optique bien structurée et organisée. Je crois que nous pouvons nous appuyer sur l'expérience d' à la fois GNOME et KDE, et aussi d'autres projets pour améliorer cette idée.
Ceci est également important pour les distributions
Les distributions majeures tendent à avoir de grosses versions, ainsi que plus de versions fréquentes. RHEL a Fedora, Ubuntu a ses versions LTS, Debian prend la cadence avec sa continuité logique extrême avec Sid et Testing :-). (NDT: au cas où, je précise que ça n'a rien de péjoratif dans l'original)
Quand nous avons fait Ubuntu 6.06 LTS, nous avons dit: "nous ferons une autre LTS dans 2 ou 3 ans". Quand nous avons fait 8.04 LTS, nous avons dit que les bénéfices de la prédictabilité d'une LTS était telle qu'il serait bien de définir à l'avance quand la prochaine LTS sortirait. J'ai dis que j" aimerais que ce soit la 10.04 LTS, un cycle majeur de 2 ans, jusqu'à ce que l'opportunité de coordonner notre sortie LTS avec une ou deux autres distributions majeures - Debian, Suse ou Red Hat, se présente.
J'ai discuté avec des gens chez Novell, et il semble qu'il n'y ait pas d'opportunité pour une coordination pour le moment. En conversant avec Steve McIntyre, l'actuel dirigeant du Projet Debian (Debian Project), nous avons trouvé une occasion intéressante pour collaborer. Debian vise un cycle de 18 mois, ce qui place la prochaine version aux alentours d' Octobre 2010, ce qui sera à peu près la date de sortie d'Ubuntu 10.10. Potentiellement, nous pouvons déférer la Ubuntu LTS jusqu'à la 10.10, se coordonner et collaborer avec le Projet Debian pour une version avec des choix similaires pour l'infrastrucure globale. Celà permettrait un partage de correctifs simplifié, un bénéfice à double sens. Vu qu'il y a aura beaucoup de gens d'Ubuntu à la debconf, et je l'espère des développeurs Debian à l'UDS de Barcelone en Mai, nous aurons l'occasion d'examiner tout celà en détail. Si il y a la volonté, l'excitation et l'envie générale d'une telle idée chez Debian, je proposerais de bon coeur l'idée de déférer la LTS de la 10.04 à la 10.10.
Questions et possibilités
Alors, que devrait être la "meilleure pratique" pour un méta-cycle? Quelle genre de choses doivent être prise en compte pour planifier ces méta-cycles? Quels problèmes amènent-elles, et comment les résoudre le plus efficacement? Comment les cycles courts (3 mois, 6 mois) peuvent se placer dans un méta-cycle plus large? Poser ces questions à travers de multiples communautés permettra de tester ces idées et d'en générer de meilleures.
Quel serait le bon nom pour de tels méta-cycles? Les méta-cycles semblent très.... méta.
Est-ce vrai que la première version d'un cycle majeur (KDE 4.0, Python 3.0) est mieux faite sur un cycle court qui ne requiert pas d'attention à long terme? Y a t-il d'autres ou de meilleures exemples de celà?
Quelle version dans le cycle majeur est la plus apte à être une version supporté à long terme? Est-ce la dernière version avant un changement majeur (Python 2.6? Gnome 2.28?) ou est-ce le résultat de la correction des plus gros problèmes de cette nouvelle versions (KDE 4.2? Gnome 3.2?). Est-ce que c'est réllement important? Je crois qu'il est plus avantageux pour les développeurs de maintenant une version occasionelle pour un temps plus long qu'habituellement, car c'est ce que les grandes structures veulent.
Est-ce qu'un cycle d'un an est réellement si bénéfique? Par exemple, est ce que 2.5 ans pourrait être une bonne idée? Personnellement, je pense que non. Je crois que les conférences et les vacances tombent au même moment de l'année chaque année et qu'il est beaucoup, beaucoup plus facile de penser en termes de nombre de cycles par an. Mais lors de discussions sur ce sujet, certaines personnes disent que 18 mois, d'autres disent que 30 mois (2 ans et demi) pourrait mieux convenir. Je pense qu'ils sont cinglés, qu'en pensez vous?
Si c'est 2 ou 3 ans, quel est le mieux pour vous? Les fans de hardware diront "2 ans!" pour pouvoir profiter au plus vite de nouveaux matériels. Les fans de logiciels diront "3 ans!" pour avoir moins de modifications à prendre en charge dans les logiciels. Personnellement, je serais dans le camp des 2 ans mais je crois qu'il est plus important de s'aligner avec la volonté de la communauté, et si GNOME / KDE / Le noyau choisissaient 3 ans, je serais ravis de le faire aussi.
Comment concilier les méta-cycles de différents projets? Est ce que celà fait sens d'avoir des cycles pour le bas-niveau, ce qui est lié au hardware, sur un cycle différent de celui de haut-niveau, ce qui est visible par l'utilisateur? Ou ne serait-il pas plus censé d'avoir un rythme de vie partagé à la fois par le haut et le bas d'une distribution?
Ne serait-il pas plus judicieux d'échelonner les versions supportés à long terme sur la façon dont elles dépendent d'une autre, comme GCC puis X puis OpenOffice? N'y aurait-il pas plus de sens que tous ces projets suivent le même méta-cycle, ce qui permettrait de grosses modifications par un principe pyramidal avec de nombreux projets en même temps, et aussi une stabilité accrue vis à vis des uns aux autres.
Y-a t-il déjà un projet quelque part qui fonctionne sur ce système?
Une conversation inter-communauté
Si vous avez lu ce texte, jusqu'ici, merci à vous! Merci de faire un commentaire, et si vous êtes intéressé alors merci de poser ces questions à la communauté qui vous tient à coeur, et de faire part ici des résultats de ces discussions en commentaire. Je suis persuadé que nous pouvons amener "l'art" du logiciel à un niveau supérieur si nous prenons avantage du fait que nous NE sommes PAS propriétaires, et celà est une des clés pour le faire.
_____________________________________________________________________________________________
Donc voilà, le point de vue me parait intéressant et loin d'être idiot, et un rapprochement avec debian comme il le propose ne peut qu'être bénéfique. Ce qui me dérange quand même est surtout vers la fin où il finit quand même discrètement par reproposer son histoire d'un calendrier définie pour tous les projets. J'étais déjà contre de par la non-liberté de la chose, et là, je retrouve le côté mégalo du monsieur où il en vient quand même à dire ce que devrait être l'agenda de x, open office ou autre.
Si c'est libre et choisi par chacun comme avec debian, oui et tant mieux, si c'est mark shuttleworth qui veut l'imposer à d'autres projets parce qu'il est sûr d'avoir raison, je suis déjà beaucoup moins pour. A voir jusqu'à quel point il veut aller là dedans. Reste que son post reste ouvert à toutes les idées donc je la relaie vu que tout celà me parait intéressant et avoir d'autres opinions l'est aussi.
