Cela faisait un moment que j'attendais la nouvelle. Je guettais la page régulièrement (je n'ai que cela à faire, rassurez-vous). Et ce soir 11h passé, c'est le bon jour. Le compteur est enfin sous la barre des 100 :
" Number concerning the next release (excluding ignored and not-in-testing): 94 "
Il n'est pas dis que demain, cela soit encore le cas. Ces derniers temps, cela a pas mal fluctué entre 100 et 110. Mais bon, cela va dans la bonne direction.
La page qui va bien pour les accros des debians stables ;-)
http://bugs.debian.org/release-critical/
Journal Etch sous la barre des 100
9
jan.
2007
# C'est qui Etch
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Etch est la future version stable de debian qui est en phase terminale. Le nombre que j'évoque ici est le nombre de bogue critique qu'il reste à corriger avant publication de Etch en version stable. En effet, chez debian, on publie à zéro bogue critique le jour J, ou plutôt, le jour J est le jour ou le nombre de bigue critique atteint zéro.
Pour celui ou celle qui va sur la page web relatant des derniers bogues corrigé ou nouveau, il (elle) verra qu'il y a pas mal d'activité ces derniers temps.
Le site web de debian au cas ou (et puis cela augmente le page rank de debian) :
http://www.debian.org/
[^] # Re: C'est qui Etch
Posté par Matthieu Lemerre . Évalué à 10.
Moi au contraire je pense que Debian a encore de beaux jours devant elle ;)
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 5.
Par contre je trouve la page que tu utilises pour surveiller le nombre de bugs critique un peu austère.
Personnellement j'orienterais plus volontiers vers cette page [1], plus attractive, qui explique clairement les enjeux de la chasse aux bogues, et qui incite joyeusement à contribuer à la qualité de la distribution. (moi je la recharge toutes les deux secondes avec un dog [2]* pipé dans diff [3] et je suis averti en temps réel de la moindre modification).
*cette page car [4] semble avoir disparu
[1]http://dunc-bank.zoy.org/
[2]http://packages.debian.org/unstable/source/dog
[3]http://www.gnu.org/software/diffutils/
[4]http://jl.photodex.com/dog/
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à -2.
Quand je vais sur la page indiquée je ne vois pas d'incitation à contribuer à la qualité de la distribution.
Je ne vois que des gens qui veulent retarder Etch le plus possible :
The Dunc-Bank is an experiment to see how aggressive bug reporting can delay the release of Debian Etch.
We hope that by finding more and more RC bugs in Debian we can delay Etch.
Franchement je trouve ça complètement imbécile et scandaleux. C'est exactement le concept de la grève du zèle pour pouvoir tout bloquer.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 6.
Après tout, il y a des gens payés pour les corriger, maintenant, les bugs.
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à -1.
Voilà. La jalousie à l'état brut.
Le ton se veut humoristique mais il est juste pathétique de bêtise.
un exemple ou ils se réjouissent que les bugfix d'ubuntu soit durs à intégrer :
We do not have any sponsors, but we wish to thank the Ubuntu project for not making it too easy to merge bug fixes back into Debian. Keep up the good work!
Tu peux m'expliquer en quoi le fait que des bugfix ne soient pas facile à récupérer "améliore la qualité de la distribution" ?
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 10.
Si les bugfix d'Ubuntu ne sont pas très faciles à intégrer dans Debian (ce en quoi, soit dit en passant, Dunc-Bank n'est absolument pas responsable, c'est quand même le comble d'attaquer le projet là-dessus !), alors Etch est retardée. Si Etch est retardée, alors nous avons plus de temps pour trouver des bugs critiques et ainsi améliorer la qualité de la distribution.
Sinon, tu peux m'expliquer quelle serait ta stratégie pour corriger les bugs d'Etch qui n'ont pas encore été trouvés ? Parce qu'il faut bien que quelqu'un les trouve ; si tu parviens à les corriger sans les trouver, tu es bien fort. Mais je suppose que tu préconises plutôt de ne rien faire et de nier l'existence des bugs que Dunc-Bank trouve. C'est tellement plus facile, et c'est vrai que ça aide vachement. En plus, en ne faisant rien, on aide toutes les distributions en même temps, c'est un bel exemple de collaboration dans le libre (mais il faut quand même poster des conneries sur LinuxFr.org de temps en temps pour que les gens soient au courant qu'on ne fait rien, sinon ça ne se voit pas assez).
[^] # Re: C'est qui Etch
Posté par bz31 . Évalué à 0.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402772
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 3.
[^] # Re: C'est qui Etch
Posté par bz31 . Évalué à 2.
Et aussi ta réponse à http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403330
(Je suis sur une powerpc, donc les codecs win32 ne me concerne pas, par contre ça sera bien si le nouveau support vc1 soit dans etch.)
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Il a tagué le bug "confirmed", je ne vois pas ce qu'il te faut de plus.
[^] # Re: C'est qui Etch
Posté par bz31 . Évalué à 1.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 1.
[^] # Re: C'est qui Etch
Posté par ola . Évalué à 1.
Elle a bon dos la discussion saine.
quand je lit ca :
We hope that by finding more and more RC bugs in Debian we can delay Etch.
je me dit que l'essence meme de dunc bank est d'etre anti productif au possible...
le but du jeu n'est pas d'ameliorer etch, mais juste de la retarder pour n'importe quel motif.
Le but ultime est visiblement de juste faire echouer dunk tank, pour pouvoir leur dire "ah ben vous voyez, ca marche pas, on vous l'avez dit, Ha-Ha!!".
'fin bref, arreter de prendre les gens pour des jambons, et eviter de faire passer une querelle interne pour une procedure de QA.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 5.
J'ai bon ?
[^] # Re: C'est qui Etch
Posté par ola . Évalué à -1.
En quoi faire des estimations correctes du boulot restant a faire est broken by design?
La totalite de l'industrie moderne fonctionne comme ca, et pourtant ca a l'air de tres bien marcher...
Ensuite la seule chose qui va etre montree par l'experience c'est que les mecs de dunc bank sont des irresponsables, caracteriels et jaloux...
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 4.
Par contre, pour les projets qui fonctionnent à la satisfaction du client, il semble que la bonne recette soit de mettre un peu d'eau dans le vin de la planification spécification totale, et de corriger/implémenter petit à petit.
Ne pas prétendre dès le début qu'on sait exactement à quoi ressemblera le produit fini, et encore moins le temps qu'il faudra pour le construire.
[^] # Re: C'est qui Etch
Posté par ola . Évalué à 0.
C'est sur que quand on sait pas ou on va, c'est pas possible de mettre une deadline...
M'enfin c'est gonfle de venir donner des lecons de QA et de gestion de projet quand a l'etape du freeze, on ne sait toujours pas ce qu'on est cense produire, tu m'excuseras...
La totalité des SSII fonctionnent comme ça. La quasi totalité des projets dépasse les deadlines.
2 choses :
1) les deadlines sont depasses car le client tire le prix vers le bas au max. Pas l'impression qu'il y ait grand monde qui tire quoi que ce soit vers le bas dans le cas de debian
2) entre deriver de pourcents et atomiser la date prevue en doublant le temps de dev initialement prevu, ya une certaine difference...
Bref, mauvaise foi, mauvaise foi, quand tu tiens...
Pourquoi vous ne l'admettez pas clairement?
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
Bah si justement, dunc-tank. Ils tirent la qualité vers le bas pour releaser plus vite. Le modèle Ubuntu, quoi.
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
Dunc-tank nuit à la qualité de la distribution. Le but de ce projet est d'empêcher ça. À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank. Ce qui a doublement réussi puisque de nouvelles méthodes de QA ont été inventées conduisant à une amélioration globale de la qualité, et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
Et Sam de conclure : « J'adore qu'un plan se déroule sans accroc. »
[^] # Re: C'est qui Etch
Posté par ola . Évalué à 0.
J'ai du mal a saisir comment tirer publiquement dans les pattes de ses collegues va ameliorer la qualite.
et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
mouais, enfin la grande question est : est ce que le retard aurait ete inferieur a un mois si certains n'avaient pas volontairement freine des 2 pieds pour porter ce delai a plus d'un mois?
[^] # Re: C'est qui Etch
Posté par imalip . Évalué à 5.
Honnetement ? Ben c'est pas dur. L'installeur n'est toujours pas pret, la doc non plus, ni le noyau. Sujets dans lesquels autant que je sache aucun des membres de dunk-bank ne s'est impliqué.
Franchement, si dunk-tank a montré quelque chose, c'est que le DPL et son équipe n'ont pas su voir ce qui posait probleme pour la release, et on alloué des moyens aux RMs pour lesquels il n'y avait rien a redire niveau boulot, alors que ce sont d'autres aspects du projet qui étaient en retard.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 9.
Depuis le début j'ai l'impression que tu considères « sorti à la date prévue » comme un gage de qualité ; c'est vraiment un critère bizarre, non ?
[^] # Re: C'est qui Etch
Posté par briaeros007 . Évalué à 3.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 2.
En revanche je n'ai pas encore très bien compris en quoi et pour qui c'était négatif de retarder Etch.
[^] # Re: C'est qui Etch
Posté par Jean-Philippe (site web personnel) . Évalué à 0.
Si il manque du temps ce sera surtout les specs qui seront abandonnées d'après ce que je vois du dev.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Ah, parce que la release d'edgy ne s'est pas faite ? Première nouvelle...
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 4.
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à 3.
On parlait de cette phrase :
Ils tirent la qualité vers le bas pour releaser plus vite. Le modèle Ubuntu, quoi.
Donc la question était la qualité de la distro et tes arguments ne parlent pas de la qualité mais des licences donc tu est hors-sujet.
Sinon je suis d'accord avec toi pour penser que drivers graphiques proprios sont inacceptables...mais Ubuntu ne les envisage que pour la prochaine release (et encore c'est pas fait). Si cette mesure est adopté et que l'installation se fait par défaut je me casse de chez eux.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 3.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 2.
Simple utilisateur debian attaché à la qualité du produit fini plus qu'à sa date de sortie (il est là pour durer, le produit), je ne suis pas la personne qui peut argumenter le mieux pour déterminer si oui ou non quelque chose tire debian vers le bas.
Attaquer Dunk Bank c'est un peu comme mettre des baffes au gamin qui dit que le roi est nu...
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 8.
Chaque semaine la release prenait du retard, chaque semaine le nombre de bugs RC décroissait quatre fois moins vite que ce qui était attendu. Et à chaque point fait par les release managers, la réaction était : « on est en retard, eh bien il suffit de travailler plus, et on releasera à temps ».
Dans « release manager » il y a quand même « manager », et aucun des deux RM n'en avait la carrure. Steve Langasek est un excellent technicien, qui a une connaissance parfaite du projet, et abat un boulot absolument énorme ; il n'y a vraiment rien à redire quant à sa contribution technique. Andreas Barth est clairement un cran en-dessous, mais bon, il n'a quand même pas chômé, soyons gentils. En revanche ils ont été soit nuls soit malhonnêtes en gérant le projet :
ø début novembre, ils annoncent un retard du freeze mais pas de la date de release alors qu'il reste 310 bugs ;
ø début décembre, le jour qui aurait dû être celui de la release, il reste 160 bugs, toujours pas de freeze, et on a droit à un nothing too dramatic [...] in good progress ;
ø fin décembre, ils décident de freezer ; il reste 116 bugs alors que la limite avait été fixée à 80, ce qui signifie que le passage des paquets d'unstable à testing sera bien plus ardu, et que le nombre de bugs baissera plus lentement.
Et durant tout ce temps, aucune précision ou amélioration sur le nouveau calendrier ou les outils de gestion (lors de son premier rapport dunc-bank, Andreas Barth disait qu'il avait du mal à estimer les tendances de l'évolution du nombre de bugs parce qu'il aurait fallu pouvoir suivre séparément le nombre de bugs ouverts et le nombre de bugs fermés ; un mois -- de salaire -- plus tard, un tel graphe n'était toujours pas apparu). Alors elle est où, l'estimation correcte ? Dans mon cul, à mon avis.
[^] # Re: C'est qui Etch
Posté par ola . Évalué à 1.
Si le management est incompetent (en vrai j'en sais rien, j'ai pas de quoi juger), soit.
Maintenant, expliquer le probleme un peu mieux ne ferait pas de mal, parce que la tu vois, t'es passe tout seul pour un agite du bocal en faisant des privates jokes de geek initie alors qu'au final c'est pas si evident que ca (pas si evident car je n'ai pas les moyen de verifier, encore une fois).
Bref, c'est pas le tout d'etre de bonne foi et de penser avoir raison, faut encore etre capable de le faire comprendre aux autres (et le pire c'est que t'en es visiblement capabel, vu la reponse que tu viens de faire).
Bref entre "bouh, dunk tank c'est nul, ils payent des dev et pas d'autres, on va tout faire pour faire capoter le truc" et la reponse que tu viens de me donner, ya un monde...
Derniere chose, j'ai pas dit que l'estimation faite par le management debian etait correcte, juste que c'etait pas "broken by design" de faire une estimation correcte, nuance.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 6.
Et excuse-moi, mais qui crois-tu convaincre en disant qu' « au final c'est pas si évident que ça » ? Qui peut imaginer que tout seul, avec la position hyper stratégique que j'occupe dans Debian (y'a qu'à voir les responsabilités de malade que j'accumule, je suis, euh, humoriste en chef, et puis j'ai des centaines d'hommes sous mes ordres qui font tout ce que je leur demande et des fois je les prive de pizza quand ils sont pas sages ou qu'ils ne disent pas assez de mal de Mandriva) je peux retarder de trois mois le travail de 1000 hommes dont plusieurs payés à temps plein ? C'est du délire, ce serait comme si deux mecs armés de cutters pouvaient tuer 3000 hommes dans une tour. Ahaha.
[^] # Re: C'est qui Etch
Posté par ola . Évalué à 0.
ben visiblement, on est quelques uns normalement constitue dans ces colonnes a l'avoir prit plus ou moins au serieux. Recherche dunc bank dans la pitite boite en haut a droite, tu verras bien.
Disons qu'abstraction faite du ton et des images, on se doute qu'il ya qqchose de serieux deriere.
Ce qui a l'air d'etre le cas, vu comment tu prends le sujet a coeur.
Et excuse-moi, mais qui crois-tu convaincre en disant qu' « au final c'est pas si évident que ça » ?
j'ai l'impression qu'on s'est mal compris.
Par "pas si evident que ca", j'entendais qu'a la lumiere de ton commentaire, c'etait pas evident que l'initiative soit simplement un conflit de personnes.
En revanche, ta page dunc bank donne simplement l'impression de vouloir casser du dunk tank.
C'est tout.
Apres ya ptetre eu mauvaise comprehension, mais faut etre 2 pour ca...
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 2.
Et le but ultime de dunc-tank ce n'est pas de dire « ah ben vous voyez, ça marche on vous l'avait dit, ha ha ! ». Quelle différence ? À part bien sûr que dunc-tank préconise de sortir Etch à une date précise alors que Dunc-Bank préconise de retarder tant qu'on peut trouver des bugs RC.
Je suis par ailleurs surpris qu'aucun donneur de leçons n'ait encore attaqué Dunc-Bank au sujet des images de Skeletor et d'Hannibal Smith qu'on trouve sur le site, à côté d'une liste de bugs énonçant polices et documentations non-libres dans les paquets Debian. 2007 commence mollement.
[^] # Re: C'est qui Etch
Posté par ola . Évalué à -1.
Je lit ca dessus :
We hope that by finding more and more RC bugs in Debian we can delay Etch.
Le sens de cette phrase est en substance : nous esperons qu'en trouvant plein de bugs RC, on peut retarder Etch.
Ceci est renforce par le ton de la page et par le nom meme du projet, qui est une reference directe a dunk tank.
Sens qui en decoule : la recherche de bug n'est qu'un moyen pour atteindre le but "retarder Etch".
Retarder Etch est une fin en soi, c'est ce que j'appelle contre productif.
Apres si c'est pas le cas, je m'en excuse platement, mais va falloir prendre des cours de communication...
Cela dit, j'ai comme un gros doute, tu vois.
Deuxieme chose, je ne donne pas de lecons.
Je me permet juste de reagir sur le fait que tu presentes dunc bank comme une procedure QA pour debian alors que ca n'est visiblement qu'une querelle interne a debian.
Apres ce que tu fais chez debian je m'en tamponne le coquillard d'une force, mais alors d'une force...
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à 0.
Ton explication ne tient pas la route et je te le démontre (en utilisant tes propres mots) par un raisonnement par l'absurde :
"Si je met une bombe pour faire sauter les salles de serveurs de Debian alors Etch est retardée. Si Etch est retardée, alors nous avons plus de temps pour trouver des bugs critiques et ainsi améliorer la qualité de la distribution."
Est-ce que tu pense que faire sauter les serveurs va améliorer la qualité de Etch ? Je pense que non. Donc le fait que les fixs d'Ubuntu sont durs à intégrer ne va pas plus améliorer la distribution...donc s'en réjouir est stupide.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 5.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 1.
[^] # Re: C'est qui Etch
Posté par feth . Évalué à 3.
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à -1.
Pourquoi parle-tu d'analogie alors que j'ai écrit noir sur blanc que c'était un raisonnement par l'absurde.
Je pense que cela démontre clairement ta mauvaise foi dans cette affaire...ou alors le fait que tu ne connais pas cet outil réthorique, auquel cas je te conseille de lire http://fr.wikipedia.org/wiki/Raisonnement_par_l'absurde
Dunc-Bank n'est pas une tentative d'améliorer la qualité de Etch. C'est juste la manifestation d'une jalousie malsaine envers des gens qui sont payés pour bosser sur Etch.
[^] # Re: C'est qui Etch
Posté par hokata . Évalué à 6.
Ou alors c'est une tentative humoristique de dénoncer une pratique et d'en estimer les limites ?
[^] # Re: C'est qui Etch
Posté par Sam Hocevar (site web personnel) . Évalué à 3.
Je dis que A a pour conséquence B (bugs Ubuntu => retard Etch) et que B a pour conséquence C (retard Etch => davantage de temps pour trouver des bugs), j'en conclus que A est une bonne chose parce qu'elle permet C, et c'est vrai si A n'a pas d'autre conséquence néfaste, j'aurais pu le préciser, c'est vrai, surtout que c'est sur ce point qu'il y aurait lieu de débattre.
Ta démonstration est juste, et ce que tu montres en partant de A' (faire sauter les serveurs Debian) c'est simplement que A' a aussi des conséquences néfastes, donc ce n'est pas une bonne chose. Merci du scoop. Faire sauter les salles serveur, c'est pas bien !
Et sinon, c'est quoi ton vrai problème avec Dunc-Bank, à part ta jalousie malsaine de ma maîtrise de Gimp pour faire des images rigolotes ?
[^] # Re: C'est qui Etch
Posté par patrick_g (site web personnel) . Évalué à -1.
Excellent argument ! Que dirai-tu si je te reprochais d'avoir écrit "Wikipédo" au lieu de Wikipédia ?
>> Et sinon, c'est quoi ton vrai problème avec Dunc-Bank, à part ta jalousie malsaine de ma maîtrise de Gimp pour faire des images rigolotes ?
Je dois t'avouer que je n'avais même pas vu les images. Je m'étais contenté de lire le texte. Je viens d'aller y refaire un tour pour me rendre compte et, effectivement, cela donne un ton humoristique qui n'est pas trop présent dans le texte (ou trop épisodiquement).
Je persiste à penser que ce site ne rend pas service à Debian et attise les ressentiments inutilement.
Mais bon c'est peut-être juste que je suis insensible à cet humour glacé et sophistiqué ;-)
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
Et si tu arrêtais de brasser du vent ?
[^] # Re: C'est qui Etch
Posté par Lucas . Évalué à 3.
Je m'étais amusé il y a quelques semaines à comparer la "qualité" d'Ubuntu Dapper et de Debian Etch à l'aide d'une métrique qui vaut ce qu'elle vaut. Le résultat était que Etch était déjà de meilleure qualité que Dapper. Cf http://www.lucas-nussbaum.net/blog/?p=224
D'autre part, il faut noter que cette notion de nombre de bugs critiques est assez artificielle. Il y a des bugs critiques très simples à corriger (la plupart des bugs que j'ai signalé en cherchant des paquets qui ne rebuildaient pas le sont), et d'autres très très difficiles à corriger. De plus, il y a des bugs qui affectent des paquets sans lesquels on ne peut raisonnablement pas releaser, et d'autres qui qui affectent des paquets avec un score popcon très faible. Pour faire baisser le nombre de bugs RC, il suffirait alors de supprimer ces paquets là.
# Plus que 14 pour le freeze...
Posté par portninwak_ . Évalué à 4.
[^] # Re: Plus que 14 pour le freeze...
Posté par GCN (site web personnel) . Évalué à 8.
Mesdames et Messieurs utilisat{rice,eur}s de Debian, reportez tous les bugs possibles et imaginables, c'est pas possible il doit en rester encore plein ! Faites un petit effort, on n'est qu'en 2007 là c'est beaucoup trop tôt...
Hop => Dodo :)
# Tiens, question bête...
Posté par iznogoud . Évalué à 5.
Après la release de la sarge le 6 juin 2005 (nombre de bugs connus : 0), on a un pic montant de bugs arrivant d'un coup (mi juillet), qui pourrait correspondre à une mise à jour du compteur pour passer de sarge à etch. Rien de trop anormal.
Le pic qui m'étonne beaucoup plus est celui de mi janvier 2006. Quelqu'un sait ce qui s'est passé ?
A noter que la différence entre all critical bugs et all concerned by next release suivent une courbe très proche, à 500 bugs de différence entre les deux près. C'est intéressant de remarque ainsi que la qualité de la "next release" par rapport au nombre total de critiques est relativement constante.
Il y aurait en fait pas mal à dire sur ce graphe je trouve :)
[^] # Re: Tiens, question bête...
Posté par imalip . Évalué à 6.
Ca correspond a la transition qui consistait a virer le package xlibs-dev, forcant a avoir une dependance a la compilation uniquement sur les packages de X necessaires. Pour le coup, Adeodato Simó a rempli (automatiquement je suppose) plus 500 rapports de bugs, cf http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=adeod(...)
# Désolé pour la douche mais …
Posté par Pierre Habouzit . Évalué à 2.
Bref, le rythme de fix est toujours négatif, on approche à nouveau des 100 bugs. Désolé donc de te couper ainsi dans ton élan.
[^] # Re: Désolé pour la douche mais …
Posté par Pierre Habouzit . Évalué à 1.
http://people.debian.org/~sesse/bugscan/
Il y a juste un décrochement, mais si on l'ignore, on a une belle courbe grimpante bien stable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.