Journal Présentation sur "git bisect" au Linux Kongress 2009

Posté par  (site web personnel) .
Étiquettes : aucune
11
9
nov.
2009
J'ai fait une présentation intitulée 'Fighting regressions with "git bisect"' au Linux Kongress 2009 à Dresde en Allemagne le 29 octobre dernier.

Les slides de la présentation sont disponibles ici et l'article au format PDF là et au format HTML ici.

On parle même de ma présentation à la fin de cet article du H online.

  • # petite remarque concernant les liens

    Posté par  . Évalué à 10.

    Les liens tels que "ici" ou "là" sont difficilement accessibles pour plusieurs raisons :
    1) leurs intitulés (ici et là) sont peu évocateurs : quelqu'un qui a besoin d'assistance pour trouver les liens d'une page aura bien du mal à comprendre quelle ressource se trouve au bout du lien (lorsqu'on liste les liens d'une page par exemple)
    2) ces petits mots sont parfois difficiles à repérer pour certains déficients visuels
    3) ces petits liens sont parfois difficilement cliquables pour les personnes à mobilité réduite.


    Pensez donc à créer de beaux liens (comme "Linux Kongress 2009") dont l'intitulé (le texte matérialisant le lien sur la page) est à la fois évocateur, renseigne sur le type de ressource qu'on va trouver lié et assez large pour qu'on ne le loupe pas.

    Sinon bravo pour les slides :)

    • [^] # Re: petite remarque concernant les liens

      Posté par  . Évalué à 0.

      Le problème, c'est que dans son cas, j'aurais écrit 3 fois "Linux Kongress 2009", ce qui n'aide pas plus à la lisibilité.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: petite remarque concernant les liens

      Posté par  (Mastodon) . Évalué à 3.

      Et en plus, les documents seront moins bien référencés parce que le texte du lien compte dans le référencement du document...

    • [^] # Re: petite remarque concernant les liens

      Posté par  . Évalué à 6.

      C'est toujours mieux que les [1], qui sont pour le moins très pénibles et pourtant je ne vois personne le rappeler.






      [1] le fameux lien

      • [^] # Re: petite remarque concernant les liens

        Posté par  . Évalué à 4.

        Tu rigoles, c'est génial la pelletée de liens en vrac qui correspondent à rien à la fin.

      • [^] # Re: petite remarque concernant les liens

        Posté par  . Évalué à 2.

        C'est "presque bien" lorsque les liens sont correctement documentés :
        exemple
        [1] [a]Lien ver le document important1[a]
        et pas
        [1] lien vers le document important1 : [a]http://url.super.pas.parlante.com/[/a]

        Je dis presque bien car pour la personne qui utilise les listes de liens, c'est top, mais pour une personne qui voit bien, c'est assez lourd. Ça permet en fait de ne pas avoir a modifier le texte pour créer une cohérence entre le discours et le libellé du lien (ce qui est souvent nécessaire pour avoir à la fois de beaux liens et un texte compréhensible)
        C'est pour ça que personne ne critique cette méthode, parce qu'elle est relativement "neutre" et qu'elle crée seulement un désagrément léger, elle ne bloque pas l'accès à l'information.

    • [^] # Re: petite remarque concernant les liens

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

      J'avais lu un article sur cette pratique qui s'appelle le "here-linking" je crois, mais difficile de trouver quelque chose sur le net à ce sujet, ces mots sont trop référencés...

  • # Durée

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

    C'était combien de temps ?
    Car 75 pages de présentation, avec beaucoupbeaucoup de redondance (car je fais pas la différence entre deux pages dont seul le checksum du commit change), c'est pas mal indigeste !
    Je rententerai de lire tout ça plus tard, car là, ça m'a vite achevé…

    Quel a été, objectivement, l'accueil du public ?

    • [^] # Re: Durée

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

      C'était 45 minutes. Et effectivement j'avais beaucoup de pages donc je suis allé très vite sur chaque. (Et oui j'ai réussi à ne pas dépasser les 45 minutes.)

      Sinon l'accueil du public a été plutôt bon. En particulier je crois que Dirk Wetter le chairman du program committee du Linux Kongress était très content.

      Mais bon le Linux Kongress ce n'est pas énorme comme manifestation. Il y avait en tout une centaine de personnes et la plupart ont décidé d'aller voir la présentation qui était faite en même temps que la mienne ou alors d'aller se balader en ville ou se reposer, car il y avait une vingtaine de personnes environ à ma présentation.

  • # KISS

    Posté par  . Évalué à 3.

    Waouh, 75 pages à ingurgiter pour comprendre comment rechercher un bug par dichotomie.
    A ce prix là, je préfère les rechercher à la main.

    Avec le paquet de commandes qu'il y a, il faut croire en la réincarnation pour espérer maitriser parfaitement la bête.
    http://www.kernel.org/pub/software/scm/git/docs/

    Hg vaincra !
    http://mercurial.selenic.com/wiki/BisectExtension

    • [^] # Re: KISS

      Posté par  . Évalué à 2.

      Plus sérieusement, la présentation était certainement appropriée pour proposer un nouvel algorithme (si j'ai à peu près compris) mais n'intéresse pas directement les utilisateurs.

      Ce qui aurait été bien, c'est d'en extraire la présentation du bisect avec les bonnes pratiques.
      Ca aurait mieux correspondu au titre, non ?

      • [^] # Re: KISS

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

        La présentation et l'article décrivent pas mal de chose :

        - la problématique des régressions et certains moyens pour les résoudre
        - les sous commandes de git bisect et comment elles s'utilisent
        - les principaux algorithmes et les raisons pour lesquels ils sont utilisés
        - les meilleures pratiques
        - un peu certaines commandes liées (git rev-list et git replace)
        - un peu les évolutions possibles

        donc il n'y a pas de miracle, ça prend de la place.

        Et c'est destiné principalement à des développeurs avancés, en particulier des développeurs du noyau Linux vu l'audience du Linux-Kongress.

        Pour les utilisateurs, il y a la page de manuel de git bisect: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h(...)

        Et il y a aussi l'article que j'ai écrit en février dernier pour LWN.net: http://lwn.net/Articles/317154/

        Enfin une petite recherche sur son moteur préféré permet de trouver pas mal de choses, en particulier des utilisateurs qui décrivent leur expérience (le plus souvent très positive) avec la bête.

        Concernant le nombre de commandes de Git, pour une utilisation normale voire même avancée, il y a besoin de seulement une vingtaine de commande, ce sont les commandes renvoyées par git help (sans arguments). Les autres commandes sont de la plomberie (plumbing) qui est surtout destinée à être utilisée par des scripts ou pour du debug ou des utilisations spéciales.

        • [^] # Re: KISS

          Posté par  . Évalué à 2.

          Don't feed the troll.

          Ta présentation est malgré tout intéressante hors du contexte des kernel hackers et même hors du contexte de Git.

          J'ai cependant une petite question.
          Sur les slides 48 et 49 , tu montres le cas où un mauvais commit peut être suivi d'un fix et où le bisect s'arrête.
          Est t'il possible de relancer un bisect inversé pour repérer le "first good commit" pour pouvoir ensuite le réappliquer à la régression et cela a t'il un intérêt ?

          Sinon merci pour les infos.

          • [^] # Re: KISS

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

            Oui effectivement, c'est possible et c'est même utilisé. (C'est sur les slides 47 et 48.)

            Il y a déjà eu plusieurs personnes qui ont demandé un mode inversé dans lequel bad et good sont intervertis justement pour cela. Il y a même eu des patchs postés sur la liste, mais ils n'étaient pas complets et donc ça n'a pas été intégré.

            • [^] # Re: KISS

              Posté par  . Évalué à 3.

              Merci et félicitations pour ton optim !

        • [^] # Re: KISS

          Posté par  . Évalué à 1.

          Un point qui m'a paru intéressant, c'est ta citation d'Ingo Molnar, page 16 du livret, qui présente sa manière d'utiliser l'outil.

Suivre le flux des commentaires

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