Journal Etch sous la barre des 100

Posté par  (site web personnel) .
Étiquettes : aucune
0
9
jan.
2007
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/
  • # C'est qui Etch

    Posté par  (site web personnel) . Évalué à 7.

    Evidement, pressé de faire mon journal vu que je n'était pas sur que le compteur ne repasse pas au dessus de la barre des 100, je ne me suis à peine relu et donc je n'ai même pas parlé du contexte.

    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  . Évalué à 10.

      Etch est la future version stable de debian qui est en phase terminale.


      Moi au contraire je pense que Debian a encore de beaux jours devant elle ;)
    • [^] # Re: C'est qui Etch

      Posté par  . Évalué à 5.

      En effet tu as raison de souligner l'info, ça fait plaisir !
      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  (site web personnel) . Évalué à -2.

        >> 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.

        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  . Évalué à 6.

          Rechercher et signaler des bugs c'est mauvais pour la qualité de la distribution ?
          Après tout, il y a des gens payés pour les corriger, maintenant, les bugs.
          • [^] # Re: C'est qui Etch

            Posté par  (site web personnel) . Évalué à -1.

            >> Après tout, il y a des gens payés pour les corriger, maintenant, les bugs.

            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  (site web personnel) . Évalué à 10.

              C'est pourtant évident, mais visiblement tu sembles trop aveuglé par ton envie d'insulter. « Pathétique de bêtise, » ça aide à poser les fondements d'une discussion saine.

              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  . Évalué à 0.

              • [^] # Re: C'est qui Etch

                Posté par  . Évalué à 1.

                mouais...
                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  . Évalué à 5.

                  Pour résumer la raison du pourquoi, je crois qu'on peut dire que dunc tank et les releases à dates fixes c'est broken by design (en plus d'être méprisant pour les bénévoles), et que comme beaucoup de gens ne veulent pas le comprendre, il faut leur montrer par l'expérience.
                  J'ai bon ?
                  • [^] # Re: C'est qui Etch

                    Posté par  . Évalué à -1.

                    broken by design?

                    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  . Évalué à 4.

                      La totalité des SSII fonctionnent comme ça. La quasi totalité des projets dépasse les deadlines.

                      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  . Évalué à 0.

                        Ne pas prétendre dès le début qu'on sait exactement à quoi ressemblera le produit fini
                        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  (site web personnel) . Évalué à 7.

                          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
                          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  . Évalué à 0.

                            À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank.

                            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  . Évalué à 5.

                              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?

                              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  (site web personnel) . Évalué à 9.

                              Mais qui a volontairement freiné des deux pieds ? Je n'en connais pas beaucoup ; trois ou quatre, peut-être, et la plupart ne le disent pas. En revanche Dunc-Bank a travaillé d'arrache-pied pour trouver le maximum de bugs RC qui auraient eu un impact négatif sur la distribution si on ne les avait pas trouvés.

                              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  . Évalué à 3.

                                amha , ce qui le gene ce n'est pas de trouvé des bugs qui nuisent à la qualité c'est d'essayer trouver des bugs dans le seul but de retarder etch (et non pas pour améliorer etch).
                                • [^] # Re: C'est qui Etch

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Oh ben oui, j'ai bien compris : non seulement il faut bosser davantage mais en plus il faut le faire avec des intentions saines, sinon houlala c'est mal.

                                  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  (site web personnel) . Évalué à 0.

                            Groan, ok ubuntu est moins fignolé que debian mais si il ya des problèmes majeurs les releases ne se font pas quand même...

                            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  (site web personnel) . Évalué à 2.

                              Groan, ok ubuntu est moins fignolé que debian mais si il ya des problèmes majeurs les releases ne se font pas quand même...
                              Ah, parce que la release d'edgy ne s'est pas faite ? Première nouvelle...
                              • [^] # Re: C'est qui Etch

                                Posté par  (site web personnel) . Évalué à 2.

                                C'est quoi le problème majeur d'edgy qui aurait du empêcher la release ?
                                • [^] # Re: C'est qui Etch

                                  Posté par  . Évalué à 4.

                                  Les firmwares non libres, les drivers proprios, ou alors le logo de firefox, ou euh, hotbabe ? Quoi ? Ils s'en foutent de tout ? Ben alors rien.
                                  • [^] # Re: C'est qui Etch

                                    Posté par  (site web personnel) . Évalué à 3.

                                    >> Les firmwares non libres, les drivers proprios, ou alors le logo de firefox, ou euh, hotbabe ? Quoi ? Ils s'en foutent de tout ? Ben alors rien.

                                    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  . Évalué à 3.

                                      # modprobe recul humour distance 2nddegre
                                • [^] # Re: C'est qui Etch

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Le fait que c'est buggé au point d'en être inutilisable ?
                        • [^] # Re: C'est qui Etch

                          Posté par  . Évalué à 2.

                          Il me semble que justement on n'est pas à l'étape du freeze. Ce freeze sera déclenché par la suppression/correction/downgrade d'un bug quelconque. Bon ok, pauvre mouche.

                          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  (site web personnel) . Évalué à 8.

                      Des estimations correctes ? Mais c'est du foutage de gueule à l'état brut, ce que tu dis.

                      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  . Évalué à 1.

                        ben on retombe dans ce que je disais plus bas : communiquez un peu mieux que ca, bordel...

                        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  (site web personnel) . Évalué à 6.

                          À mon avis les agités du bocal sont ceux qui croient se faire une idée de ce qui se passe chez Debian en regardant le site de Dunc-Bank. Ce site web, c'est un délire, je ne vois pas comment un individu normalement constitué peut prendre ce site au sérieux rien qu'en en voyant les images.

                          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  . Évalué à 0.

                            Ce site web, c'est un délire, je ne vois pas comment un individu normalement constitué peut prendre ce site au sérieux rien qu'en en voyant les images.

                            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  (site web personnel) . Évalué à 2.

                  Alors Dunc-Bank est anti-productif en trouvant des bugs ? Et les release managers de Debian, lorsqu'ils mettent des bugs critiques en etch-ignore parce que « on n'aura pas le temps de s'en occuper », ils sont productifs ? On croit rêver.

                  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  . Évalué à -1.

                    Ben ecoutes, c'est ton site, c'est ptetre meme toi qui l'a redige (en tout cas t'en es assez proche, vu ton lien page perso).

                    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  (site web personnel) . Évalué à 0.

                Mais pourquoi se réjouir du fait que des fixs sont durs à intégrer ????
                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  (site web personnel) . Évalué à 5.

                  Il faut s'en réjouir parce que la qualité des fixes Ubuntu est absolument à chier. C'est bien simple, à chaque fois que j'ai un patch qui vient de chez Ubuntu, je finis par le réécrire en grande partie avant de l'intégrer.
                • [^] # Re: C'est qui Etch

                  Posté par  (site web personnel) . Évalué à 1.

                  Faire l'analogie entre l'impact d'Ubuntu sur les bugs Debian et celui d'une bombe qui fait sauter les salles serveur de Debian, je n'en attendais pas tant. Bravo et merci !
                  • [^] # Re: C'est qui Etch

                    Posté par  . Évalué à 3.

                    Each time you report an RC bug, the time bomb in debian's datacenter ticks (and a kitten gets killed, also).
                  • [^] # Re: C'est qui Etch

                    Posté par  (site web personnel) . Évalué à -1.

                    >> Faire l'analogie entre l'impact d'Ubuntu sur les bugs Debian et celui d'une bombe qui fait sauter les salles serveur de Debian, je n'en attendais pas tant. Bravo et merci !

                    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  . Évalué à 6.

                      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.


                      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  (site web personnel) . Évalué à 3.

                      Avant de me prendre de haut, apprends peut-être à écrire « rhétorique », ça fera un peu moins « houlala je vais vite voir dans Wikipédo ce que je vais pouvoir répondre ».

                      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  (site web personnel) . Évalué à -1.

                        >> Avant de me prendre de haut, apprends peut-être à écrire « rhétorique », ça fera un peu moins « houlala je vais vite voir dans Wikipédo ce que je vais pouvoir répondre ».

                        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  (site web personnel) . Évalué à 4.

                          Je persiste à penser que ce site ne rend pas service à Debian et attise les ressentiments inutilement.
                          Et si tu arrêtais de brasser du vent ?
      • [^] # Re: C'est qui Etch

        Posté par  . Évalué à 3.

        Perso, je préfère utiliser http://stats.zoy.org/cgi-bin/cricket/grapher.cgi?target=%2Fd(...) , qui a l'avantage d'être apolitique.

        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  . Évalué à 4.

    Non, je déconne.
    • [^] # Re: Plus que 14 pour le freeze...

      Posté par  (site web personnel) . Évalué à 8.

      Non... Si les bugs sont corrigés trop rapidement, la prochaine Debian ne respectera pas la tradiction ancestrale de la release dite "When it's ready" (nom scientifique: Debiantu too-latus releasum) !

      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  . Évalué à 5.

    http://bugs.debian.org/release-critical/graph.png

    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  . Évalué à 6.

      Le pic qui m'étonne beaucoup plus est celui de mi janvier 2006. Quelqu'un sait ce qui s'est passé ?

      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  . Évalué à 2.

    si le nombre de bugs est passé en dessous de 100 c'est parce qu'il y avait un pb d'index corrompu sur le server qui décompte les bugs, et donc ça a chutté d'un seul coup lorsque ça a été réparé.

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.