Je ne vois absolument pas en quoi le fait de mettre trois ans à preparer une release, en incluant, du coup, de tres nombreux et importants changements, est gage d'une meilleure qualité.
Peut tu m'éclairer ?
De nombreux projets libres choisissent, au nom de la qualité, justement, de faire des releases fréquentes (eg. le kernel linux, apache) voir fréquentes et prévisibles dans le temps (eg. Gnome, OpenBSD).
Chaque release inclue alors un nombre limité de changements. L'attention de tout les developpeurs et testeurs porte sur ces changements car ils sont en nombre suffisament limité pour être listables et bien connus de tous. Si l'un de ces changements s'avere necessiter plus de travail (est trop buggué), il est "backouté" (enlevé) avant la release. Bref, des evolutions frequentes plutot que des revolutions, cela permet un travail très focalisé.
Cette demarche permet en outre d'appuyer les developpements suivants sur des bases saines et bien établies, évitant de perdre du temps par exemple avec des bugs mysterieux lors de l'integration d'une nvlle version d'x.org parceque la version de gcc ou du kernel n'est pas encore bien au point (alors que si on a fait une release auparavant incluant le nouveau gcc, les bugs seront bien polis et/ou connus)...
Je me souviens que pendant son cycle de developpement, Sarge a intégré successivement un gnome 2.2, puis un 2.4, puis un 2.6 (avec à chaque fois de nouveaux bugs, de nouveaux rapports de bugs etc.). Que de temps perdu, pour les devs et les testeurs ... à chaque fois je pensait qu'il s'agissait de la version qui sera intégré dans la release et je passer beaucoup de temps à tester ... tout ça bien sûr parceque la release tardait à venir ...
D'autre part les analyses concernant ce problème de temps de release pour Sarge par des membres de la release team et des ftp masters évoquent généralement des problèmes d'infrastructure (serveur de compilation en panne, trop d'architectures, membres de la release team occupés sur ubuntu, etc.). En tout cas tout les developpeurs important (y compris les leaders sucessifs) s'accordent à reconnaitre qu'il y a là un problème majeur.
J'ai l'impression que seuls les dévots Debian (non developpeurs) refusent encore de considérer le temps de dev de Sarge comme un problème, au nom du très falacieux et légerement sybilin "on release quand c'est pret" (btw: donne moi une definition, stp, du "c'est pret").
Ceci dit sans préjuger de Debian, que je trouve d'excellente qualité. Mais elle ne le restera (de bonne qualité) qu'à condition que ses developpeurs et utilisateurs sachent être objectifs pour analyser les points faibles. En particulier le problème d'échéance des releases.
[^] # Re: sorties prévisibles ????
Posté par herodiade . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 0.
Peut tu m'éclairer ?
De nombreux projets libres choisissent, au nom de la qualité, justement, de faire des releases fréquentes (eg. le kernel linux, apache) voir fréquentes et prévisibles dans le temps (eg. Gnome, OpenBSD).
Chaque release inclue alors un nombre limité de changements. L'attention de tout les developpeurs et testeurs porte sur ces changements car ils sont en nombre suffisament limité pour être listables et bien connus de tous. Si l'un de ces changements s'avere necessiter plus de travail (est trop buggué), il est "backouté" (enlevé) avant la release. Bref, des evolutions frequentes plutot que des revolutions, cela permet un travail très focalisé.
Cette demarche permet en outre d'appuyer les developpements suivants sur des bases saines et bien établies, évitant de perdre du temps par exemple avec des bugs mysterieux lors de l'integration d'une nvlle version d'x.org parceque la version de gcc ou du kernel n'est pas encore bien au point (alors que si on a fait une release auparavant incluant le nouveau gcc, les bugs seront bien polis et/ou connus)...
Je me souviens que pendant son cycle de developpement, Sarge a intégré successivement un gnome 2.2, puis un 2.4, puis un 2.6 (avec à chaque fois de nouveaux bugs, de nouveaux rapports de bugs etc.). Que de temps perdu, pour les devs et les testeurs ... à chaque fois je pensait qu'il s'agissait de la version qui sera intégré dans la release et je passer beaucoup de temps à tester ... tout ça bien sûr parceque la release tardait à venir ...
D'autre part les analyses concernant ce problème de temps de release pour Sarge par des membres de la release team et des ftp masters évoquent généralement des problèmes d'infrastructure (serveur de compilation en panne, trop d'architectures, membres de la release team occupés sur ubuntu, etc.). En tout cas tout les developpeurs important (y compris les leaders sucessifs) s'accordent à reconnaitre qu'il y a là un problème majeur.
J'ai l'impression que seuls les dévots Debian (non developpeurs) refusent encore de considérer le temps de dev de Sarge comme un problème, au nom du très falacieux et légerement sybilin "on release quand c'est pret" (btw: donne moi une definition, stp, du "c'est pret").
Ceci dit sans préjuger de Debian, que je trouve d'excellente qualité. Mais elle ne le restera (de bonne qualité) qu'à condition que ses developpeurs et utilisateurs sachent être objectifs pour analyser les points faibles. En particulier le problème d'échéance des releases.