Journal Remonter l'historique du noyau avec git depuis le début

• # Correction

  Posté par claudex le 18 septembre 2018 à 19:15. Évalué à 10.

  

  Je me suis permis de corriger le markdown du dernier commit qui déconnait un peu.

  Merci pour le journal.

  « 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: Correction

    Posté par benoar le 19 septembre 2018 à 08:20. Évalué à 4.

    

    Merci. Il y a également les deux derniers blame qui n'apparaissent pas pareil que les deux premiers. J'étais pressé et j'ai posté tel-quel.

    Franchement j'ai horreur de markdown, j'ai toujours des incohérences incompréhensibles. Je fais toujours du ReST qui est beaucoup plus logique et vraiment puissant, tout en étant plus lisible. Pas étonnant que ça ait été le choix des devs noyau plutôt que du markdown…

    • [^] # Re: Correction

      Posté par claudex le 19 septembre 2018 à 08:50. Évalué à 5.

      

      Voilà c'est fait.

      Souvent les erreurs viennent des 4 caractères pour indenter le code. Je préfère les ``` au début et à la fin du bloc de code.

      « 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: Correction

        Posté par benoar le 19 septembre 2018 à 10:18. Évalué à 3. Dernière modification le 19 septembre 2018 à 10:18.

        

        Merci pour les corrections, c'est beaucoup plus lisible.

        J'avais oublié les ```, en effet, ça semble plus simple.

    • [^] # Re: Correction

      Posté par raphj le 19 septembre 2018 à 14:33. Évalué à 1.

      

      Je ne sais jamais comment on fait pour mettre un code dans une puce ou dans une citation en Markdown et j'ai bien galéré sur mon dernier journal avec ça.

      Dans une vie antérieure, j'ai conçu une syntaxe dans laquelle ça se passe comme ça :

       - La version avec `echo` :
          [code=bash <<<
              echo "toto"
          >>>]
      
       - La version avec `printf` :
          [code=bash <<<
              printf "toto\n"
          >>>]
      

      Ou, si on veut être plus explicite :

       - La version avec `echo` : [
          [code=bash <<<
              echo "toto"
          >>>]
       ]
      
       - La version avec `printf` : [
          [code=bash <<<
              printf "toto\n"
          >>>]
       ]
      

      Pour une citation :

      Voici ce que cette page disait :
      
      [quote
          Ce code ne fonctionne pas toujours comme attendu :
          [code=bash <<<
              echo "$message"
          >>>]
      ]
      

      Pour les titres, pas de caractères bizarres : un = au début de la ligne donne un titre de premier niveau, deux = donnent un titre de deuxième niveau et il est également possible d'utiliser une notation sous forme de sections du genre :

      [ = Titre 1
          Cette section présente tartempion, un dessert peu connu.
      
          [ = Titre 1.1
              Lorem ipsum...
          ]
      ]
      

      Et c'est d'ailleurs transformé en sections HTML. Les espaces de début de lignes dans les blocs de code sont détectés et supprimés, en conservant malgré tout l'indentation du code. Le code du document lui-même peut en conséquence être indenté.

      On sort de l'esprit Markdown qui est censé être lisible tel quel, mais finalement ici on ne voit jamais que le résultat HTML et je préfère que ce soit facile à écrire et à comprendre plutôt que « plus ou moins naturel » à lire.

      Je n'aime pas du tout Markdown non plus, et faire des contorsions pour écrire ce que je dois écrire. Je préfèrerais pouvoir rédiger dans un langage style (X)HTML (il n'est pas vraiment question d'utiliser autre chose y compris la syntaxe que j'ai mentionnée plus haut, elle aurait probablement les mêmes problèmes que je trouve à Markdown pour d'autres gens de toute façon). Les règles sont extrêmement claires et simples et il n'y a pas d'histoire de « Oh, la liste n'est pas reconnue comme une liste parce qu'elle n'est pas entourée de lignes vides », ou « Ah, j'ai trop indenté les tirets de cette liste, du coup elle est reconnue comme un bloc de code ». Ou « J'ai mis une nouvelle ligne entre deux items de la liste, donc c'est reconnu comme deux listes ». Tu veux écrire une citation ? Alors tu la mets entre <citation> et </citation>. Aucun mystère ou comportement étrange pour quelqu'un qui n'a pas l'habitude.

      • [^] # Re: Correction

        Posté par BAud (site web personnel) le 19 septembre 2018 à 15:28. Évalué à 3. Dernière modification le 19 septembre 2018 à 15:28.

        

        cela donnerait :

        • la version avec echo :

        echo "toto"

        • la version avec printf :

        printf "toto\n"

        Pour une citation :

        Voici ce que cette page disait :

        Ce code ne fonctionne pas toujours comme attendu :

                echo "$message"

        tout est à base de ce qui est indiqué sur la page wiki aide-edition, le point important à retenir est qu'il faut souvent ajouter une ligne blanche préalable (et la prévisualisation permet d'essayer).

        spoiler : utiliser ```bash en le faisant précéder d'une ligne blanche

        • [^] # Re: Correction

          Posté par raphj le 19 septembre 2018 à 17:00. Évalué à 4. Dernière modification le 19 septembre 2018 à 17:04.

          

          Merci pour l'aide-edition, mais dans ton message, les blocs de codes sont hors des puces, et d'ailleurs chaque puce est dans une liste différente. Voici ce que donne "Code source de la sélection" dans Firefox :

          <ul>
          <li>la version avec <em>echo</em> :</li>
          </ul>
          
          <pre><code class="bash"><span class="nb">echo</span> <span class="s2">"toto"</span></code></pre>
          
          <ul>
          <li>la version avec printf :</li>
          </ul>

          Y a-t-il moyen d'éviter ça ?

          Peut-être que beaucoup pensent que je chipote mais j'attache de l'importance à ce genre de choses.

          À la personne qui m'a moinsé : je suis intéressé par savoir ce j'ai écrit de gênant pour éviter de recommencer à l'avenir.

          (edit: et effectivement j'avais réussi pour le code dans une citation, mais je n'avais pas trouvé la syntaxe que j'ai utilisée élégante / intuitive - je suppose que c'est une question de goût personnel, là on n'y peut pas grand chose)

          • [^] # Re: Correction

            Posté par BAud (site web personnel) le 19 septembre 2018 à 18:05. Évalué à 4.

            

            Y a-t-il moyen d'éviter ça ?

            a priori non, en l'état, du fait qu'actuellement il faut ajouter une ligne blanche pour que le code soit pris en compte, ainsi que la liste à puce => peut-être faire évoluer le transcodage du Markdown.

            la syntaxe pour le code dans une citation est élégant avec le Markdown je trouve 'fin bon, comme tu dis question de goût :

            > Ce code ne fonctionne pas toujours comme attendu :
            >
            >```bash
            > echo "$message"
            >```

            (tu noteras la fameuse ligne intercalaire…)

            • [^] # Re: Correction

              Posté par raphj le 20 septembre 2018 à 01:03. Évalué à -2. Dernière modification le 20 septembre 2018 à 01:05.

              

              Effectivement, l'évolution de la traduction Markdown -> HTML que tu mentionnes me paraît être une bonne idée. Je peux écrire une entrée dans le suivi pour ça si ça paraît utile à quelqu'un.

              Ah, effectivement c'est élégant comme ça. Il me semble que j'avais trouvé une autre manière de faire (que je n'ai pas trouvé élégante) ou alors ma mémoire me fait défaut.

              Bref, je ne suis pas fan du Markdown, peut-être en partie parce que je ne le pratique pas assez, mais trouver une syntaxe qui plairait à tout le monde est probablement une idée assez utopique de toute façon.

              Sinon, est-ce que ça vaudrait le coup que je crée une entrée dans le suivi pour proposer une option qui permet à l'utilisateur de saisir un commentaire / un journal en HTML (à voir pour les dépêches et l'interaction que cette option pourrait avoir avec l'aspect édition collective des dépêches), quitte à ce que cet HTML soit épuré et transformé ? (pas d'utilisation de styles, de scripts, d'iframes, d'objets, toutes les balises fermantes correspondent à des balises ouvrantes et vice-versa). Quitte à ce que ce soit une option proposée à partir d'un certain karma pour limiter les éventuels problèmes de sécurité non anticipés que cela pourrait poser. Je n'ai aucune idée si ça a déjà été discuté par le passé.

              Ça permettrait aux grincheux comme moi d'utiliser la syntaxe qu'ils / elles veulent pour rédiger, y compris l'HTML directement.

              • [^] # Re: Correction

                Posté par raphj le 20 septembre 2018 à 01:47. Évalué à 1. Dernière modification le 20 septembre 2018 à 01:50.

                

                Pour référence, voilà comment j'avais fait (sans les espaces en début de lignes, mais je ne sais pas comment citer correctement un code markdown pour produire un bloc de code) :

                    > Voici un code dans une citation :
                    >
                    ```
                    echo "salut"
                    ```
                    Un texte dans la citation après le code.
                

                ---

                Et là, ce qui suit pète tout. Je passe deux lignes vides, puis j'indente une ligne avec 8 espaces, puis je passe une ligne vide et je commence à écrire "J'essaie de […]" :

                    texte indentée ?
                ```J'essaie de sortir du bloc de code. Je n'ai pas écrit les trois guillemets qui débutent cette ligne, ils apparaissent tout seuls. Par contre, j'avais passé une ligne qui a disparu. Si je ne passe pas la ligne, ce comportement n'apparaît pas. Idem si je ne passe qu'une ligne et pas deux avant le "texte indenté ?".
                
                
                
                
                Je n'arrive pas à sortir de ce bloc de code.
                
                J'espère que j'ai réussi à être compréhensible mais ce n'est pas évident. Je suis tombé sur ce comportement en essayant de citer un code.
                
                À plus :-]
                
                P.S.: Voici la source de ce commentaire : https://framabin.org/p/?e8c3707081753b1b#evPLh7aVALnU5XG6riKUUV966jDFT8EQhCwptTv3vLU=
                
                P.P.S : on a des comportements amusants en insérant des ``` dans ce bloc de code.
                

                • [^] # Re: Correction

                  Posté par BAud (site web personnel) le 21 septembre 2018 à 00:11. Évalué à 3.

                  

                  je ne sais pas comment citer correctement un code markdown pour produire un bloc de code

                  classiquement, il y a le code d'échappement \ à placer aux endroits opportuns pour gêner la regexp et ne pas prendre en compte les codes markdown…
                  m'enfin, t'inquiète, je suis un maniaque du bouton Prévisualiser pour m'assurer que cela s'affiche comme je m'y attends :-)

                  Le mode de Markdown avec le préfixe par caractères espace est le plus embêtant àmha, 'fin celui qui m'embête le plus (et toi aussi, vu que ça n'indente pas). Donc, je ne cherche plus à indenter :p et, oui, la ligne préalable parfois ça marche, parfois pas… ou pas tout le temps O_o

                  Pour revenir sur un point que tu évoquais plus haut, pour la gestion des titres, il y a deux modes de fonctionnement :

                  • le préfixé par #, ## ou ### selon le niveau souhaité (bon il y a parfois un bug dans la table des matières — si tu démarres au niveau 2 sans niveau 1 au-dessus — pas visible immédiatement vu qu'elle ne s'affiche que lorsque dépassés les 2000 caractères iirc)
                  • l'encadré : toujours avec les # (je trouve ça inutile mais bon)
                  • le souligné : ça je trouve que c'est lourd
                  • bon, ça fait 3 modes :D

                  c'est décrit sur https://linuxfr.org/wiki/aide-edition#titres

                  et il y a des fonctions cachées liées à des effets de bord des regexp… mais bon avoir fait du lex/yacc (rapidement remplacé par flex+bison…) à une époque où la seule doc' était la théorie des regexp / le code a dû irrémédiablement dédier une partie de mon cerveau a retenir les syntaxes de wiki o_O et trouver ce qu'on peut faire avec (ou pas).

                  • [^] # Re: Correction

                    Posté par raphj le 21 septembre 2018 à 08:32. Évalué à 2.

                    

                    Merci BAud de prendre tout ce temps à me lire et me répondre !

                    Je suis moi aussi un gros utilisateur du bouton prévisualiser et son utilisation obligatoire est une bonne chose.

              • [^] # Re: Correction

                Posté par BAud (site web personnel) le 21 septembre 2018 à 00:15. Évalué à 3. Dernière modification le 21 septembre 2018 à 00:15.

                

                Sinon, est-ce que ça vaudrait le coup que je crée une entrée dans le suivi pour proposer une option qui permet à l'utilisateur de saisir un commentaire / un journal en HTML

                ça existait à l'époque de templeet pour l'édition des dépêches quand j'étais modo, mais bon, c'était un peu le dernier recours…

• # En fabriquer un dépôt git pour l'historique?

  Posté par Babelouest (site web personnel) le 18 septembre 2018 à 21:33. Évalué à 10.

  

  Une idée me vient à l'esprit en lisant ton journal.

  Serait-ce un chouette projet pour la postérité de faire un repository git qui contiendrai tout l'historique du noyau linux disponible avec les métadonnées disponibles (date, qui a commité, commentaire, etc.)?

  J'avoue, ca ressemble à un projet de moine archiviste qui n'est peut-être pas utile en soi.

  Mais ca peut avoir de l'intérêt pour un éventuel chercheur/journaliste/curieux/insomniaque qui veut faire des statistiques ou des analyses sociales liées aux commits dans le code source du noyau, voire pour une autre raison qui m'échappe parce que liée à un domaine qui n'existe pas encore ou que je ne connais pas…

  Je me fourvoie?

  • [^] # Re: En fabriquer un dépôt git pour l'historique?

    Posté par Renault (site web personnel) le 18 septembre 2018 à 23:00. Évalué à 7.

    

    Un peu comme https://www.softwareheritage.org/?lang=fr mais avec le lien entre les différents historiques du noyau ?

  • [^] # Re: En fabriquer un dépôt git pour l'historique?

    Posté par AncalagonTotof le 19 septembre 2018 à 07:37. Évalué à 6.

    

    Ou encore :

    Gource / Linux (YouTube)

    Ça sert à rien, mais c'est joli ;-)

  • [^] # Re: En fabriquer un dépôt git pour l'historique?

    Posté par benoar le 19 septembre 2018 à 08:23. Évalué à 7. Dernière modification le 19 septembre 2018 à 08:23.

    

    C'est un projet qui a été mené par Dave Jones, comme cité dans la page SO. Il a un dépôt du code utilisé :
    https://github.com/kernelslacker/linux-historic-scripts
    Et la page qui héberge le résultat :
    https://archive.org/details/git-history-of-linux

    Mais ça n'était pas satisfaisant pour moi, qui cherchait un découpage plus précis. Rechercher les patchs originaux de la branche de Linus n'est vraiment pas facile, mais ça serait en effet un travail intéressant, je pense.

    • [^] # Re: En fabriquer un dépôt git pour l'historique?

      Posté par pulkomandy (site web personnel, Mastodon) le 19 septembre 2018 à 09:23. Évalué à 10.

      

      Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).

      • [^] # Re: En fabriquer un dépôt git pour l'historique?

        Posté par claudex le 19 septembre 2018 à 10:08. Évalué à 8.

        

        Le lien: https://github.com/dspinellis/unix-history-repo

        Il y a plusieurs branches en fonction des différentes versions mais ce n'est que pour FreeBSD (et ses ancêtres).

        « 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

• # Tiens, à propos, comment-vous gérez vos repos, vous ?

  Posté par Dring le 19 septembre 2018 à 09:20. Évalué à 5.

  

  Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.

  C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.

  Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.

  Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/… Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.

  Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).

  Du coup, vous avez juste :
  - le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
  - votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
  - perdu le détail des itérations du code

  Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.

  Bref…

  En gros, la question c'est :
  - est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
  - ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
  - ou avez-vous d'autres approches ?

  • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par jihele le 19 septembre 2018 à 09:54. Évalué à 6.

    

    Je ne comprends pas trop.

    Dans git, quand tu intègre une branche dans ta branche principale, tu as un commit de merge (toujours s'il y a un merge, ou optionnellement si c'est du fast-forward) mais tu récupères aussi dans l'historique les commits de la branche de dev, donc tu as rien perdu et tu peux supprimer la branche de dev car elle ne comporte aucune info supplémentaire.

    Concrètement, le commit de merge est juste un commit qui a deux parents : le dernier commit de la branche master et celui de la branche de dev. Donc on peut remonter tous les commits de la branch de dev. Et si on veut pas se trimballer plein de commits temporaires dans master, on peut squasher les commits de la branch de dev avant intégration, mais on aura au moins un commit de dev avec une trace écrite.

    Du coup, vous avez juste :
    - le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
    - votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
    - perdu le détail des itérations du code

    Ben non, vous avez le commit de merge et au moins un commit de dev qui indique qui a codé et vous conservez les itérations que vous voulez (squash ou pas).

  • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par benoar le 19 septembre 2018 à 10:25. Évalué à 7. Dernière modification le 19 septembre 2018 à 10:25.

    

    • est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver

    Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.

  • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par pulkomandy (site web personnel, Mastodon) le 19 septembre 2018 à 13:20. Évalué à 8.

    

    Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.

    Il faut peut-être aller expliquer leur travail à vos intégrateurs.

    On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.

    On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.

    Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.

    Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.

    L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.

    • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

      Posté par Sufflope (site web personnel) le 19 septembre 2018 à 16:02. Évalué à 3. Dernière modification le 19 septembre 2018 à 16:03.

      

      Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.

      Concernant gitlab, depuis quelques versions, si tu commentes sur un commit, le commentaire est conservé dans la MR même si tu écrases le commit avec un push-force. Ça permet de faire une review commit par commit (l'interface de review permettant de soit voir tout le diff, soit ne voir qu'un commit à la fois). Ça plus la config pour n'autoriser le merge que s'il est fast-forward, que si les discussions sont résolues, et si la CI passe, et t'es pas mal. Même si j'imagine que Gerrit va plus loin (mais peut-être plus complexe et moins souple).

      • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

        Posté par pulkomandy (site web personnel, Mastodon) le 19 septembre 2018 à 17:05. Évalué à 4.

        

        Oui, c'est pas impossible à faire avec Gitlab mais c'est pénible.

        Gerrit permet aussi de merger un commit avant que les suivants ne soient prêts, par exemple.

        Ce n'est pas forcément moins souple, c'est juste une façon différente de travailler.

  • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par raphj le 19 septembre 2018 à 14:43. Évalué à 10.

    

    Comment vous gérez vos repos ?

    Souvent, avec un oreiller et un bon matelas :-)

Suivre le flux des commentaires

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