Ubuntu-fr

Kanoba14

Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

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.

nebaff

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

je salue l'effort de traduction

---

I5 2500 3.3Ghz,  8Go RAM DDR3, GeForce 470  Ubuntu 13.04

kao_chen

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Déjà, Kanoba14, Merci pour la traduction

Perso, ce que je comprends pas trop dans le cycle de développement actuel, c'est pourquoi les versions LTS ne profitent pas d'un cycle de gestation plus long que les versions Intermédiaires?

J'insiste sur le terme intermédiaire pour préciser que les version non LTS peuvent servir de plateforme d'intégration et de développement pour la version LTS.
Mettre en place trop vite Pulse Audio pour la 8.04LTS n'était peut être pas le meilleur choix.
On aurait du laisser PulseAudio pour une version intermédiaire.

La LTS clôture un cycle de développement de 2 ans et devrais juste stabiliser les améliorations des précédentes versions.

Sinon j'aime bien le planning des 6 mois mais un écart dans le planning pour s'adapter à une sortie de gnome 3.0 ou de debian 12 me dérange pas.
Il peut être fait et accepter par la communauté s'il est bien expliqué.
Il peut même être anticipé longtemps à l'avance, les plannings des sorties sont souvent connus à l'avance (un peu).

Mes idées ne sont pas très claires sur le sujet, mais je poste parce que ça m'intéresse et  pour apporter au moulin.

Dernière modification par kao_chen (Le 23/04/2009, à 09:44)

reeth

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Salut,

Une réponse intéressante d'un des artisants de KDE, Aaron Seigo (en anglais only). Il est intéressant de voir que les avis convergent sur de nombreux points (même si il y a forcément des divergence dues à la différence de point de vue.

/!\ Ce lien dirige vers une page web sans flash, tout le monde risque donc de pouvoir le consulter et ce même si vous utilisez gnome

Dernière modification par reeth (Le 22/04/2009, à 21:38)

seb24

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

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.

Son calendrier définie, c'est pour les gros projet inter-connecté.  Et ça me parait logique qu'il y ai une certaines coordination pour des projets majeurs de l'environnement linux, pour éviter les nombreux soucis auxquels ont peut être confrontés.

---

Mini PC NUC avec Ubuntu: ebay

poupoul2

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Pourquoi ne pas proposer ta traduction à Framalang ?

totoroavi

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Bonjour,
C'est vrais que c'est intéressant tous ça. Merci pour la traduction.
Mais d'un point de vue utilisateur, je vois que des fois tel ou tel matériel était supporté sur un version passé et il ne l'ai plus sur la version actuel ou la plus récente, je trouve cela bien dommage. Surtout quand on parle après de LTS. Perso je pense qu'une version LTS, devrais subir de nombreux teste pour être qualifier et principalement sur la reconnaissance de matériel reconnue par les versions précédente.
Qui devrais faire les testes ? Je pense que ça devrait être les utilisateurs, par exemple en s'inscrivant sur un site, donner leur configuration matériel se qui est était reconnu avant et qui ne l'ai plus.
Car je vois de plus en plus de personne "novice" qui installe des Ubuntu ou autre, tout marche bien et puis a la sortie de la nouvelle version ils l'installe et découvre qu'une partie de leur matériel n'est plus reconnue, et la commence pour eux les ennuies. Serte la communauté est souvent la pour les aidés mais je trouve ça dommage, je dirais cette perte de reconnaissance matériel.
Limite je dirais pour en revenir au cycle, qu'il faudrait un an pour un version de base (non LTS), mais une sortie en effet tout les 6 mois, je m'explique. En gros 2 versions avec un cycle d'un an décalé de 6 mois. Tous les 6 mois une version est mise au publique, l'autre est stable qu'au niveau logiciel, il reste une partie de la reconnaissance matériel a voir (en gros la différence en la stable officiel et la nouvelle) Ça éviterais je pense beaucoup de déception.
C'est beau de courir pour la reconnaissance du matériel dernière génération mais c'est dommage de perdre une partie de l'acquis passé.
Voilou
@+
totoro

---

"Le monde est dangereux non pas à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire"
(Albert Einstein)

nebaff

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

totoroavi > en fait c'est un problème relatif au noyau linux, qui embarque les pilotes matériels je pense.

Linus Tovald a d'ailleurs parlé de cela lors de la sortie du dernier noyau, et a assuré que de gros efforts seraient fait pour éliminer ce genre de soucis. La régression est en effet un soucis tres chiant.
Pour ma part les touches multimédia de mon clavier ne marchent plus qu'à moitié depuis 1 ou 2 version du noyau.

j'espere que je t'ai éclairé là dessus

Dernière modification par nebaff (Le 23/04/2009, à 13:24)

---

I5 2500 3.3Ghz,  8Go RAM DDR3, GeForce 470  Ubuntu 13.04

kao_chen

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

En fait, il a y une blueprints qui traitent du sujet des régressions lors d'une mise à jour de version.
Elle a était mis en place pour l'UDS de Jaunty.

Le but étant de trouver un moyen de détecter les régressions de matériel, et donc d'éviter les désagrément lors d'un passage vers une version supérieure.

Je vous laisse lire:
https://blueprints.launchpad.net/ubuntu/+spec/qa-jaunty-regression-tracker
qa signifiant Quality assurance.

Funkyboy

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Bonjour à tous

Kanoba14, merci beaucoup pour la traduction !

Kanoba14

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Pourquoi ne pas proposer ta traduction à Framalang ?

Je conaissais framasoft mais pas framlang, merci à toi. C'est vrai que même si ce n'était pas le but à la base et que c'est pas parfait, le plus gros du travail est fait donc je regarde tout ça pour le proposer.

Sinon, pour le fait de rallonger la période de développement des lts, je suis pas sûr que ça changerait grand chose. Par exemple, si on prend la 8.04 si ça avait commencé six mois plus tôt, pulse audio serait quand même arrivé au même moment et le temps pour l'intégrer resterait le même. Ou alors il faut tout bloquer plus tôt mais ça revient à zapper les nouvelles versions de logiciels qui pourraient être plus stable (ou aussi bien sûr introduire de nouveaux bugs), et se retrouver avec des logiciels qui ont plus d'un an, voir deux ans et demis à la fin d'une lts donc c'est vraiment le bordel aussi.

@reeth: merci pour le lien. Très intéressant, surtout que si j'ai bien suivis c'est le big boss de kde (ou son président, pas trouvé d'explication exacte) et que ça a déjà été tendu avec Shuttleworth. Au moins, y a du dialogue et des points convergents donc c'est déjà bien

Frezi

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Perso, j'attends la futur LTS vu que j'ai commencé en 8.10 et dé qu'elle est installée, je ne ferai plus que des migrations de version LTS à version LTS ce qui pour moi me semble le plus intéressent.

---

Mageia - Ubuntu 11.10 (Laptop)
Meego (Netbook)

reeth

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

@reeth: merci pour le lien. Très intéressant, surtout que si j'ai bien suivis c'est le big boss de kde (ou son président, pas trouvé d'explication exacte) et que ça a déjà été tendu avec Shuttleworth. Au moins, y a du dialogue et des points convergents donc c'est déjà bien

Oui en quelques sorte, A. Seigo est le président du conseil de KDE e.V. (l'association qui gère le projet KDE) mais il va bientôt passer la main. Il est très impliqué dans le projet kde (c'est aussi le boss de la team de dev plasma) et s'était déclaré contre la volonté de M.S. de voir le cycle de dev de KDE rejoindre celui de gnome (ils ont des méthodes/périodes de dev différentes et c'est aux distro de s'adapter, surtout que ubuntu s'est calquée sur la sortie de gnome, cela aurait obligé kde à se synchroniser sur eux alors qu'à l'époque de cette proposition kde4 était en plein chantier avec kde 4.0) ce qui avait engendré pas mal de frictions (il y en a aussi sur les systèmes de notification genre l'utilisateur doit-il pouvoir interagir avec une notification ou non ou bien à propos des system tray).

Cela dit comme tu l'exposes il y a du dialogue (surtout maintenant avec les rencontres entre dev kde/gnome) et certains points de convergence, même si il faut relativiser l'impact des propos de M.S. qui n'est pas impliqué dans la réalisation de ces projets (mais dans la packaging/finition/intégration) et qui donc avance un point de vue qui est forcément subjectif. J'aime cependant le fait qu'il donne raison au projet kde sur sa volonté de "repartir de zéro", ou tout du moins de lancer une nouvelle version vraiment différente de la précédente. Cela montre une fois de plus que le principal défaut du projet kde4 à été la communication à propos de kde 4.0 (réservée aux dev kde et avanturiers) qui à été gérée de manière désastreuse (la faute aussi aux distrib comme kubuntu qui ont voulut pousser kde4.0 alors qu'ils savaient que ce n'était pas prêt pour le grand public).

En tout cas j'ai bien aimé lire les propos de M.S. et aseigo (que j'avais vu avant celle de M.S.) car ils ont une approche assez pragmatique et intéressante.

Shrat

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Je m'interroge tout de même largement sur la possibilité de définir un optimum de release. En ce moment je tourne sur une distro rolling-release et je dois avouer que c'est très stable pour une utilisation desktop. Le rolling release donne vraiment le pouvoir aux développeurs. La philosophie Debian/Ubuntu du méga-freeze-de-la-mort-qui-tue fonctionne, elle, très bien pour les serveurs. Mais alors deux choses me viennent à l'esprit :

Ubuntu est une distrib plus audacieuse que Debian en terme de mise à jour. De fait, les migrations entre chaque version d'Ubuntu sont moins stables qu'une migration stable->testing ou même une mise à jour de la stable.

Deuxième chose, ce choix de fournir des logiciels récents se justifie par la vocation première d'Ubuntu : le desktop. Mais alors pourquoi s'emcombrer d'un système hérité de Debian.

Au final Ubuntu a apporté beaucoup concernant les outils graphiques, Arch a simplifié les fichiers de configuration. Néanmoins, en terme de rythme des sorties, je trouve que la solution d'Arch convient mieux. Je ne vois pas pourquoi un système desktop va embêter des devs avec des histoires de freeze (parfois absurdes). Tout se joue upstream de nos jours...

Pire, avec les soucis que j'ai eu sur Ubuntu, si maintenant un néophyte me demande GNU/Linux, je lui met Debian. J'aurais trop peur de mettre Ubuntu entre les mains de ma mémé.

Au final, je trouve que la question de l'optimalité de la durée entre les releases est un peu artificielle. Il faut trouver le bon dosage pour parer aux paquets qui n'auraient rien à faire dans la distrib et pour en même temps laisser un minimum de contrôle des développeurs sur leurs paquets. Ca doit être sacrément blasant de recevoir des rapports de bugs de manière incessante au sujet d'un bug corrigé il à de cela des mois.

M'enfin wala, my 2 cents... Sus aux distribs, vive les devs!

---

Mon site

reeth

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Sauf que le problème des releases ne se joue pas seulement au niveau des distrib mais aussi et surtout upstream. Donc la problématique reste la même (sur arch kde est bien la dernière version stable sortie par la team kde et dont le cycle de vie est maîtrisé).

Les sorties des softs sur les distrib (rolling release ou non) doivent donc être étudiée et améliorées si possible, et c'est tout le sens de la recherche de cet "optimum". C'est ce qui va conditionner la qualité des distribs ensuite (comme je disais à propos de kde4.0 qui a été poussé trop vite par les distribs vers les "main users" mais qui devait sortir d'un point de vue dev).

Debian/Ubuntu : ubuntu fait un instantané de debian sid qui si elle n'est pas une rolling release dans le sens du terme à une approche relativement similaire (les packages sont mis dans experimental, puis poussés vers sid après une première vérification) et est parfaitement stable.

ps: j'utilise arch (depuis peu et j'apprécie pas mal, surtout kdemod ) et debian sid/experimental (ma référence et celle que je préfère en terme de configurabilité/légèreté/temps minimum de maintenance).

Dernière modification par reeth (Le 24/04/2009, à 00:52)

sam7

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

merci pour la traduction, & pour vos commentaires très intéressant...
... à lire tout celà, ne pourrait-on pas envisager de faire une rolling release basée sur ubuntu ?
ça pourraît sans doute convenir à beaucoup (j'espère)

---

sam7 @ sweetux.org = "Faire connaître & promouvoir la culture libre"
& @ gafam.fr = "Faire connaître & promouvoir les alternatives aux GAFAMs"

Smon

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Le problème d'une rolling release, c'est que quand des paquets très importants (genre gcc ou autres) subissent un importante mise à jour, il y a des risques (plus ou moins grands) de plantages et d'incompatibilités.

L'intérêt d'un freeze sur une distrib est justement d'éviter les grosses mises à jour qui risquent de faire planter le système et qui seraient un véritable problème pour l'utilisateur non averti.

Ubuntu étant une distribution grand public, un freeze qui banni les mises à jour de version (et non les corrections de bug) semble impératif.
Même Debian, qui est déjà un peu moins tout public, a opté pour les freeze entre chaque version, et propose une version rolling distrib (la sid) pour les devs ou les personnes "qui ne peuvent pas attendre".

Mais la sid (bien que relativement stable) présenté régulièrement des problèmes de dépendances, et on est obligé de faire une mix entre la rolling distrib (sid) et les versions plus "officielles" de debian (comme la testing ou la stable).

Enfin, tout ça, c'est compliqué

---

Grâce à OpenMailBox.org, mes emails et mon cloud aussi sont libres et communautaires
Opencartographié

Smon

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

D'ailleurs, Ubuntu propose aux personnes "qui ne peuvent pas attendre" des dépôt ppa

---

Grâce à OpenMailBox.org, mes emails et mon cloud aussi sont libres et communautaires
Opencartographié

chimay

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Le problème d'une rolling release, c'est que quand des paquets très importants (genre gcc ou autres) subissent un importante mise à jour, il y a des risques (plus ou moins grands) de plantages et d'incompatibilités.

L'intérêt d'un freeze sur une distrib est justement d'éviter les grosses mises à jour qui risquent de faire planter le système et qui seraient un véritable problème pour l'utilisateur non averti.

Ubuntu étant une distribution grand public, un freeze qui banni les mises à jour de version (et non les corrections de bug) semble impératif.
Même Debian, qui est déjà un peu moins tout public, a opté pour les freeze entre chaque version, et propose une version rolling distrib (la sid) pour les devs ou les personnes "qui ne peuvent pas attendre".

Mais la sid (bien que relativement stable) présenté régulièrement des problèmes de dépendances, et on est obligé de faire une mix entre la rolling distrib (sid) et les versions plus "officielles" de debian (comme la testing ou la stable).

Enfin, tout ça, c'est compliqué

Il y a aussi la debian testing en rolling Pour l'avoir utilisée pendant des
années sans jamais vraiment de gros problème malgré des mises-à-jour
au moins hebdomadaires, je la trouve stable pour du desktop. C'est une
des seules choses qui m'ait manqué lorsque j'ai commencé à essayer ubuntu.
Tout ça pour dire que n'importe quelle distro peut très bien fonctionner sur
un système hybride testing pour desktops - impatients / releases bétonnées
pour serveurs - zens.

---

* Linux est écolo : le code est tout vert
* Un dauphin nage plus vite qu'un nautile nain
* Le but d'un système d'exploitation est d'exploiter l'ordinateur, pas l'utilisateur
* Un ordinateur est composé d'un piano, d'une mangeuse de fromage, d'une mémoire d'éléphant, d'une dalle, d'un lecteur de galette, et d'un moulin, le célèbre moulin de la galette

menoft

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Innover c'est :
- échouer vite pour réussir rapidement
- échouer rapidement et à moindre coût pour réussir
- tester, tester, tester !

À bonne entendeur.

---

---

aux modos :  est il possible de supprimer mon compte et d'anonymiser mon pseudo
Merci

Grunt

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Je trouve que M.S. prend des "grands airs" par rapport au reste de la communauté du libre..

Soit j'ai mal lu, soit il suggère de vouloir synchroniser les projets libres ensemble. Est-ce que le fait d'avoir les moyens de transformer Debian en truc instable justifie de donner ainsi des leçons? J'en doute.

Pour rappel, et sans vouloir lancer de troll, Mark Shuttleworth et Canonical, c'est:
- Ubuntu One, solution propriétaire de "Cloud Computing". A l'opposé totale des idéaux du libre.
- Du Flash sur le blog de M.S., avec comme seule réponse "Z'avez qu'à faire avancer Gnash". Dans ce cas c'était pas la peine de faire Ubuntu, y'avait qu'à améliorer Wine.
- Une distro qui s'affiche comme "Linux for human beings", mais qui zappe plus ou moins l'aspect "libre" de GNU/Linux. Approche pragmatique, soit (un peu comme celle de Linus). Mais on ne peut pas dire que Ubuntu soit un modèle de fonctionnement impeccable, son comportement est un peu étrange.

Et maintenant, tout doucement, M.S. commence à expliquer sa vision des cycles de développement (c'est très bien) et suggère d'appliquer sa vision à d'autres projets.
Je sens qu'il va méchamment se faire jeter. Il n'est déjà pas très bien vu du côté de chez Debian, pour avoir embaucher les meilleurs développeurs Debian afin qu'ils travaillent sur Ubuntu, ce qui prive Debian de forces vives: car Ubuntu ne "rend" que très peu de code à Debian.

MiNiShOoTeR

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

J'approuve ce que dit Grunt...

Mitchnumber1

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

+1 pour Grunt

---

@mvl87

Smon

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

Pas d'accord sur un point :

Le cloud computing n'est pas forcément opposé aux idéaux du libre. Tout dépend de comment tu le mets en place (dans le cas de Canonical, c'est opposé aux idéaux du libre, j'en convient).

---

Grâce à OpenMailBox.org, mes emails et mon cloud aussi sont libres et communautaires
Opencartographié

sam7

Re : Mark Shuttleworth, les cycles pour ubuntu, tout ça, tout ça

& je trouve même que ça n'est pas normal que Canonical propose un service "propriétaire" c'est en totale contradiction avec l'esprit "open source" & "Logiciel Libre"
... ça ne me plait pas trop sa nouveauté...

---

sam7 @ sweetux.org = "Faire connaître & promouvoir la culture libre"
& @ gafam.fr = "Faire connaître & promouvoir les alternatives aux GAFAMs"