Journal It's ready when it's ready, hum....

Posté par .
Tags : aucun
0
8
oct.
2007
Cher journal,

Après avoir suivi avec attention et impatience les courbes en attendant la sortie de debian Etch, je suis revenu sur cette page presque par hasard en faisant du ménage dans mes bookmarks : http://bugs.debian.org/release-critical/

Et là, surprise, une nouvelle ligne (bleue) est apparue ! En lisant la légende, celle-ci concerne le nombre de bugs de la branche stable de debian.

La hauteur de cette ligne m'interpelle, et me fait poser une question (qui a dit 'troll' ??) :
- Quel est l'intérêt de repousser la sortie d'une debian stable en attendant que celle-ci atteigne (très difficilement...) le statut de 'zéro bug connu', si c'est pour que 3 mois après, il y en ai plus de 400 ???

Du coup, alors que je trouvais ça super a vent, je trouve que le principe de sortir "when it's ready" est un peu surfait....
  • # c'est normal.

    Posté par (page perso) . Évalué à 10.

    Le Bug Tracking System de Debian utilise une feature unique à ma connaissance: la possibilité de dire à quelles versions d'un paquet s'appliquent un bug.

    Cela permet par exemple de dire que le bug #422476 a été trouvé dans la version 1.2.0-2 de openscenegraph, et qu'il a été corrigé dans les versions 1.2.0-4 d'un coté (version uploadée dans unstable), et 1.9.1-1 de l'autre (version uploadée dans experimental). Ce systeme lit les changelogs pour savoir sur quelle version une version est basée: on a donc un arbre généalogique du paquet.
    Voir:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422476
    et pour le joli dessin:
    http://bugs.debian.org/cgi-bin/version.cgi?package=openscene(...)

    Du coup, c'est merveilleux: on peut savoir quels sont les bugs qui s'appliquent à la version stable de Debian: c'est tous les bugs qui ont été trouvés dans les versions présentes dans stable.

    Oui, mais ... souvent, un bug n'est pas causé uniquement par un paquet, mais par un ensemble de paquets (ou par un changement dans un autre paquet). Prenons par exemple le bug #427463. Il a été trouvé dans la version 0.5-2 de libhpricot-ruby. Cette version est dans etch. Mais il est causé par un changement dans une de ses dépendances (ici ruby1.8 ou ruby1.9, je ne suis pas sûr) qui a eu lieu après la sortie de etch. Donc il est comptabilisé dans la liste des bugs critiques pour etch, mais il n'est pas présent dans etch.

    La solution est de marquer ces bugs là avec les tags "sid" et "lenny", pour indiquer que le problème n'est pas présent dans etch. Mais c'est assez fastidieux, et peu utile, donc rarement fait.
  • # courbes plus lisibles

    Posté par (page perso) . Évalué à 5.

    > Après avoir suivi avec attention et impatience les courbes en attendant la
    > sortie de debian Etch, je suis revenu sur cette page presque par hasard en
    > faisant du ménage dans mes bookmarks :
    > http://bugs.debian.org/release-critical/

    Si tu suis ces courbes, tu apprécieras peut-etre ces versions là:
    http://qa.debian.org/~lucas/dograph/
    graph-6m.png : courbe sur les 6 derniers mois
    graph-2y.png : courbe sur les 2 dernieres années
    graph-all.png : courbe depuis qu'elle existe, comme sur bugs.d.o/release-critical/
  • # Déception

    Posté par (page perso) . Évalué à 5.

    Moi qui croyais qu'on allais parler de duke nukem ou du hurd...
  • # ben oui

    Posté par (page perso) . Évalué à -2.

    C'est ce que je m'essaie de faire passer comme message : le principe du logiciel "produit" 0 bugs qui bougera plus est tout simplement pas adapté.

    Pire, le mode de "release 0 bugs" peut, pour certains, pousser à ne pas trop chercher les bugs.

    Pour ceux que ça intéresse, j'essaie de défendre l'approche de développement continu et time-based ici : http://ploum.frimouvy.org/?167-de-l-evolution-et-de-la-liber(...)
    • [^] # Re: ben oui

      Posté par . Évalué à -2.

      Surtout que l'un des plus gros problème de Debian est qu'il me semble qu'une majorité utilise testing et non stable. Donc une majorité de personne sont plus satisfaite avec des programmes plus récents même s'ils sont plus buggué.
      En gros, le "0 zéro" n'est pas très attractif.
      • [^] # Re: ben oui

        Posté par . Évalué à 8.

        Pour un usage personnel, je n'ai rien contre l'utilisation de testing mais en prod dans ma société je ne pense pas que je m'y risquerais. Mais à chacun sa croix
        • [^] # Re: ben oui

          Posté par (page perso) . Évalué à 1.

          sauf que voilà, lorsque en prod tu veux utiliser des modules pas disponibles dans stables (et c'est très très souvent le cas), soit tu compiles (ce qui est pire que tout à mes yeux), soit tu passes en testing, soit tu passes à une distrib qui sort des releases régulières.
          • [^] # Re: ben oui

            Posté par . Évalué à 8.

            soit tu passes à une distrib qui sort des releases régulières.

            qui seront buguées aussi mais cette fois tu sauras pas où.

            chacun sa croix...
          • [^] # Re: ben oui

            Posté par (page perso) . Évalué à 3.

            Si pour toi mettre en prod un truc qui n'a pas passé une phase de maturation ne pose pas de problème alors effectivement n'utilise pas debian stable, voila tout.

            On peut pas avoir le beurre et l'argent du beurre. Si ton modèle est si miraculeux et fonctionne si bien, bah rien ne t'empêche de créer un distribution. Si c'est si efficace, tu ne devrais pas avoir de mal à trouver des contributeurs.
          • [^] # Re: ben oui

            Posté par . Évalué à -1.

            Qu'est ce que tu entends par "distrib qui sort des releases régulières" ?
          • [^] # Re: ben oui

            Posté par . Évalué à 4.

            "Il est important de comprendre que si vous aimez le logiciel libre, ce n'est pas nécessairement pour les mêmes raisons que votre voisin. L'une comme l'autre sont valables du point de vue de chacun. " -- ploum
          • [^] # Re: ben oui

            Posté par (page perso) . Évalué à 3.

            Soit tu utilise backports.
            http://www.backports.org

            (Et traiter les utilisateurs de gentoo ou des ports *BSD de pire que tout, c'est pas trés gentil. :o) )
          • [^] # Re: ben oui

            Posté par . Évalué à 4.

            une distrib qui sort des releases régulières

            Ubuntu par exemple ?
            https://bugs.launchpad.net/ubuntu/+source/tomcat5.5/+bug/970(...)
            Bug qui empêche tout simplement de démarrer Tomcat, sans aucun message d'erreur ni log. Sympa.
  • # Ca va changer ?!

    Posté par . Évalué à 0.

    Il me semble que notre cher leader de projet debian a annoncé qu'il pensait reorganiser un peu tout ca. (he oui, comme notre cher president de la republique, que je respecte et soutiens, même pas peur de le dire )
    J'ai lau ca dans un Linux Magazine ou Linux Developper.

    D'un autre cote je prefere que debian conserve tout de même son objectif d'extreme stabilité et de respect des standards (fhs etc ...)
    Donc que debian reste debian :)

    ( si mandriva avait ete basée sur debian, je crois que j'aurais cèdé a la tentation )
    • [^] # Re: Ca va changer ?!

      Posté par . Évalué à 3.

      "je respecte et soutiens, même pas peur de le dire"

      Moi aussi, je le défends et le soutiens dans sa noble tâche.
      Bon, j'ai pas voté pour lui certes... Mais c'est pas une raison !
      Ses convictions semblent sincères et il semble motivé, d'ailleurs il ne serait pas là où il est actuellement si ses électeurs ne l'avaient pas cru, pourrait-on penser.

      Et puis, de toute façon, il n'est là que pour 1 an, donc ça va le pousser à agir vite et si ça ne se passe pas bien, on pourra toujours en changer.



      Hein ?!? C'est pas le DPL que tu affirmais respecter et soutenir ?
      Mea culpa :-p
    • [^] # Re: Ca va changer ?!

      Posté par . Évalué à 2.

      ( si mandriva avait ete basée sur debian, je crois que j'aurais cèdé a la tentation )

      Ouh la la, et du coup, t'as essayé *buntu?

Suivre le flux des commentaires

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