Bitkeeper essaye de rattraper l'histoire en passant Open Source

36
12
mai
2016
Gestion de versions

BitKeeper, logiciel de gestion de version vient discrètement de passer en Open Source, sous licence Apache 2.0. Soit plus de dix ans après l'avènement de Git dont il est indirectement à l'origine. Que de temps pour trouver le bon chemin !

logo Bitkeeper

Enfin diront certains, trop tard diront d'autres. Le changement s'est fait relativement discrètement via l'annonce assez laconique de la version Bk-7.2ce sur leur forum :

I might as well mention bk-7.2ce which is the first open-source release.

Si vous vous demandez si cela vaut le coup de laisser tomber votre SCM préféré, ils ont en place une page spécialement pour vous. Ironie de l'histoire, sur leur page de téléchargement, ils proposent de récupérer les sources de BitKeeper via Git !

Petit historique

Rappelez-vous, à partir de 2002 de nombreux développeurs et mainteneurs du noyau Linux, et pas des moindres, ont utilisé BitKeeper comme système de gestion de versions décentralisé. Outil très puissant certes, mais fortement propriétaire, développé par la société BitMover et dont la version gratuite était disponible pour les projets Open Source, mais limité fonctionnellement et les rendant dépendant de serveurs administrés par BitMover. Cela avait provoqué de grosses flamewar à l'époque.

En 2005, suite à un conflit entre l'éditeur et certains développeurs qui faisaient de le rétro-ingénierie du protocole, la version gratuite fut retirée. Pendant que ça trollait en mode « je vous l'avais bien dit », Linus se mit au travail et en deux à trois semaines, le développement du noyau reprenait sur un nouveau SCM nommé Git qui est quasiment devenu dix ans plus tard un standard de facto pour la gestion de source décentralisée.

BitKeeper vient rejoindre les déjà nombreux DVCS libres encore maintenus comme Darcs (2002), Mercurial (2005), Bazaar (2005) ou Fossil (2007).

Notes de version

Nous ne ferons pas l'historique de tous les changements depuis 10 ans. Sachez juste que cette version 7.2ce, outre sa libération, apporte

  • Une mise à jour vers TCL/Tk v8.6, ce qui améliore l'aspect sur MacOS ;
  • La correction de problèmes de performances sur des répertoires avec un grand nombre de tags ;
  • La suppression d'anciennes commandes (bk _eula, bk lease, bk legal, bk more, bk status --compat, bk users) ;
  • Une modernisation de l'interface « BK/Web service » pour qu'elle soit plus conformes aux standards d'aujourd'hui (ils semblent dater de 1998) ;
  • Plein d'autres petits détails qui parleront aux utilisateurs réguliers.

Aller plus loin

  • # Quelques explications sur la raison du passage en open-source

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

    Quelques explications supplémentaires :

    https://news.ycombinator.com/item?id=11667494 (les commentaires de Larry McVoy sont fait avec le pseudo luckydude).
    https://lwn.net/Articles/686896/

    Un point clé est « Git/Github has all the market share. Trying to compete with that just proved to be too hard. » (Git/Github a toutes les parts de marché. Essayer de concurrencer ça est trop dur).

    Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.

    • [^] # Re: Quelques explications sur la raison du passage en open-source

      Posté par  . Évalué à 10.

      Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.

      Et c'est malheureusement souvent le cas: on passe en open-source par désespoir, en espérant que soudainement, la "communauté" va venir sauver le navire du naufrage.
      Et du coup, quand ça arrive, c'est déjà trop tard, et plus personne ne s'intéresse au produit.

      Voilà! Juste un de plus!

    • [^] # Re: Quelques explications sur la raison du passage en open-source

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

      Git/Github has all the market share.

      Quand on connait (c'est dans la dépêche) la raison pour laquelle Git existe (pour résumer : ils ont eux-même déclenché la création de leur concurrent), c'est très très comique quand même : voila comment on suicide une entreprise par une décision vue comme banale à l'époque.

      Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.

      Et personne ne va s'y intéresser car on a Git. Super de la mise en open source inutile, ils mettent en open source du code qui a une valeur de $0, ça en dit long sur leur idée de l'open source.

  • # Incroyable

    Posté par  . Évalué à 6.

    Je n'avais jamais entendu parler de ce logiciel, et en lisant son histoire sur wikipedia je suis sur le cul. Je ne comprends pas comment Linus Torvalds a pu faire héberger les sources du noyau Linux sur cette plateforme étant donné le nombre très important de restrictions, par exemple :

    La possibilité de voir les méta-données et de comparer les versions précédentes est l'une des fonctionnalités principales de tout système de gestion de version, mais elle n'était pas disponible pour ceux qui ne disposaient pas d'une licence commerciale de BitKeeper, ce qui indisposait fortement la plupart des développeurs du noyau Linux.

    Il n'existait pas déjà cvs ou svn à cette époque ?

    • [^] # Re: Incroyable

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

      Si, mais pas adapté selon Linus Torvalds. D'ailleurs, même l'équipe de Subversion trouvait qu'il avait raison : https://svn.apache.org/repos/asf/subversion/branches/1.2.x/www/subversion-linus.html

      Et pour voir son avis sur CVS et Subversion : https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript https://www.youtube.com/watch?v=4XpnKHJAok8

    • [^] # Re: Incroyable

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Il n'existait pas déjà cvs ou svn à cette époque ?

      Si mais surtout il y avait déjà Darcs et Monotone en outils de gestion de versions décentralisé Open Source

      • [^] # Re: Incroyable

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

        A priori, les alternatives étaient plutôt poussives. Perso, j'ai utilisé tla/Arch pour travailler sur un fork interne de OpenWRT qui contenait également les sources du noyau, et fallait pas moins de 20 minutes pour commiter. Je crois me souvenir que c'était le même problème chez les concurrents, d'où l'insatisfaction de Linus quant à ces solutions.

    • [^] # Re: Incroyable

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

      Il n'existait pas déjà cvs ou svn à cette époque ?

      tu oses sérieusement comparer CVS/SVN à Git?

      Je n'avais jamais entendu parler de ce logiciel,

      Tu es donc jeune et n'a jamais eu à utiliser CVS/SVN sur un gros projet décentralisé…

      Je ne comprends pas comment Linus Torvalds a pu faire héberger les sources du noyau Linux sur cette plateforme étant donné le nombre très important de restrictions

      Parce qu'à l'époque, il n'y avait rien de mieux et que personne ne s'était vraiment bougé pour répondre au besoin de Linus. Linus est pragmatique, pas intégriste du libre, et prend ce qui l'arrange le plus. BitKeeper interdit, il n'a pas été enthousiasmé par les autres produits "distribués" et donc il a codé pour répondre à son besoin quand il n'a plus eu le choix ce qui montre qu'à l'époque BitKeeper était le meilleur pour son besoin.

      • [^] # Re: Incroyable

        Posté par  . Évalué à 3. Dernière modification le 13 mai 2016 à 10:08.

        tu oses sérieusement comparer CVS/SVN à Git?

        FreeBSD utilise svn et OpenBSD cvs non ? C'est ce que je vois après une rapide vérification.
        Pourquoi pas Linux alors ?

        Tu es donc jeune et n'a jamais eu à utiliser CVS/SVN sur un gros projet décentralisé…

        Je suis utilisateur "basique" de git, dans une époque où github est devenu plus ou moins un réseau social.

        • [^] # Re: Incroyable

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

          FreeBSD utilise svn et OpenBSD cvs non ? C'est ce que je vois après une rapide vérification.
          Pourquoi pas Linux alors ?

          Car SVN et CVS ne passent pas à l'échelle en nombre de contributeurs et de contributions.
          Linux, ce sont 1600 personnes par version, et 12000 commits dans le même laps de temps (2 mois).
          C'est énorme, très peu de projets ont de tels chiffres.

          • [^] # Re: Incroyable

            Posté par  . Évalué à 8.

            Il suffit de voir le temps mis par un cvs up pour avoir les corrections de stable dans openbsd pour se rendre compte comme c'est pénible. D'ailleurs, l'argument de CVS pour openbsd, c'est pour éviter les forks.

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

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

              A priori, OpenBSD a créé sa propre implémentation de CVS, appelée OpenCVS. Ils semblaient en avoir marre de GNU CVS. Ça ne les a pas incité à passer à Git ou autre système de gestion de version décentralisé…

              • [^] # Re: Incroyable

                Posté par  . Évalué à 7.

                Although CVS is widely used

                [ref nécessaire] :)

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

      Posté par  . Évalué à 1.

      Gérer le kernel avec cvs??
      Tu es sérieux là?

      svn je connais moins.

      • [^] # Re: Incroyable

        Posté par  . Évalué à 5.

        Gérer le kernel avec cvs??
        Tu es sérieux là?

        Tu as la même opinion que Linus, qui a préféré utiliser des tar avec des numéros de versions et des fichiers patch à la main pendant 10 ans plutôt que d'utiliser CVS.

        Source: https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript

        svn je connais moins.

        Aussi nul que cvs, mais sans beaucoup de ses bugs.

        • [^] # Re: Incroyable

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

          Aussi nul que cvs, mais sans beaucoup de ses bugs.

          Y'avait quoi comme super concurrent à CVS quand il est sorti (j'ai vu une rev 1.1 en 1994, ses débuts doivent donc être encore antérieurs)?

          Il n'est pas “nul” mais dépassé car il est ancien et on sait faire mieux, avec des machines nettement plus puissantes et tout plein d'outils nouveaux développés depuis.

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

          • [^] # Re: Incroyable

            Posté par  . Évalué à 6. Dernière modification le 13 mai 2016 à 15:39.

            S’il n’était pas nul subversion (dont le positionnement se limitait à « csv done right ») n’aurait jamais eu un tel succès à son époque.

          • [^] # Re: Incroyable

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

            Y'avait quoi comme super concurrent à CVS quand il est sorti (j'ai vu une rev 1.1 en 1994, ses débuts doivent donc être encore antérieurs)?

            Il y avait sccs que j'ai utilisé sur HP-UX. C'était à peu près du même niveau que RCS. CVS en est le successeur.

            • [^] # Re: Incroyable

              Posté par  . Évalué à 3.

              Tu peux toujours utiliser RCS, si tu n'as qu'un fichier à gérer en version (car en fait CVS c'est juste RCS outillé un peu pour traiter plusieurs fichiers à la fois).

              yum install rcs
              apt-get install rcs

              man ci
              man co

              très rafraichissant, comme un passage à Lascaut

        • [^] # Re: Incroyable

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

          Aussi nul que cvs, mais sans beaucoup de ses bugs.

          En fait, le gros problème de CVS (et c'est une telle limitation que l'on peut difficilement l'imaginer aujourd'hui), c'est qu'il ne tient pas compte de l'atomicité d'un commit. Chaque fichier est versionné, mais il n'est pas possible de retrouver l'ensemble des fichiers modifié ensemble à l'intérieur d'un même commit. (on peut retomber sur ces pattes en vérifiant l'heure et l'auteur, mais ça ne garantie pas le résultat).

          SVN apportait cette idée de transaction, qui permet de retrouver par un numéro de commit l'ensemble des sources affectées. Et rien que ça, c'était déjà une révolution !

          • [^] # Re: Incroyable

            Posté par  . Évalué à 2.

            Euh non, CVS aussi permettait d'avoir l'ensemble des modifs d'un commit.

            Sa non atomicité c'était que quand 2 personnes commitaient en même temps sur le dépôt (forcément central), il se pouvait que les modifs d'un commit sur un ficher passe et que celles sur un autre crée un conflit, et que simultanément, un autre commit ait le problème inverse, un peu comme un deadlock dans une base de données, mais sans l'atomicité.
            Et en suite il faut se démerder à la main pour réparer le repo.

            Subversion a corrigé ce bug (et quelques autres) tout en gardant la sémantique. Qui est nulle. Même si je le dis avec le recul et qu'à l'époque j'ai utilisé CVS avec reconnaissance, c'était mieux qu'un tar versionné.

            • [^] # Re: Incroyable

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

              CVS aussi permettait d'avoir l'ensemble des modifs d'un commit.

              Justement non. En gros, un cvs commit sur tout un projet est équivalent à for f in $(find . -type f); do cvs commit $f; done. En terme de format de stockage, l'historique de chaque fichier est stocké dans un fichier (.v), mais il n'y a rien qui relie l'historique de tous ces fichiers. Chaque fichier a un ensemble de numéros de versions, mais la version 42 d'un fichier ne correspond pas à la version 42 d'un autre.

              Regarde ce que sont obligés de faire des outils comme cvsps (et son option --fuzz) pour voir l'étendue des dégâts.

              Une des conséquences est celle que tu donnes sur les accès concurrents, mais ça n'est pas la seule.

              • [^] # Re: Incroyable

                Posté par  . Évalué à 3.

                Eh bah c'était il y a longtemps et j'étais jeune, mais je constate que j'ai oublié à quel point cvs était pauvre, pardon d'avoir dit une ânerie.

    • [^] # Re: Incroyable

      Posté par  . Évalué à 10.

      A cette époque le meilleur candidat semblait être Gnu_arch.
      https://www.gnu.org/software/gnu-arch/
      Il y avait de bonnes idées dedans mais c'était assez complexe et ça manquait de souplesse notamment pour le nommage des branches à mon sens.

      Les tenants du SVN décentralisé promouvaient svk écrit en Perl
      Il y avait de bonnes idées mais je n'ai jamais vraiment pu comprendre comment ça fonctionnait dans le détail.
      Et surtout, il conservait les même défauts inhérents à SVN qui font que ce dernier: la gestion des branches et notamment le merge rename tracking dont voici les specs et qui reste toujours complexe à mettre en oeuvre avec SVN et bancal
      Pour le dev du kernel c'est un point essentiel.
      Pour du trunk dev à la "agile" avec des branches de patchs, c'est moins crucial.

      Monotone était lui aussi déjà de la partie. https://lwn.net/Articles/132000/
      Un outil très propre, écrit en C++ avec une vision différente des branches à la Gnu Arch/Git.
      Pas de référence local/distante pour gérer les évolutions concurrentes mais la notion de plusieurs heads pour une même branche.
      Une branche est dons une forme de sous-graphe.
      Je soupçonne Mercurial de s'en être largement inspiré

      Darcs, écrit en Haskell, intéressant mais je n'ai jamais vraiment pu appréhender l'intérêt de la théorie des patchs même encore aujourd'hui.

      En tous cas, cette explosion d'idées et d'échange de toutes parts était passionnante.
      Les protagonistes de chaque outil échangeaient entre eux et tentaient de faire ressortir tous les concepts liés aux outils de VCS:
      Il y avait un super wiki (defacé depuis) qui consignait tout ça.
      Certains ont essayé de récupérer des bribes sous Github: https://github.com/tonyg/revctrl.org

      Certains ont même dégagé des patterns de SCM
      http://www.bradapp.com/acme/branching/scm-pats-intro.html.
      Je vous en conseille vivement la lecture pour avoir un regard plus détache sur vos workflows.
      ```

  • # Bazaar maintenu ?

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

    les déjà nombreux DVCS libres encore maintenus comme […] Bazaar (2005)

    Il y a eu une cinquantaine de commits sur les 4 dernières années (cf. aussi openhub) de développement de Bazaar. « Maintenu » est un bien grand mot, c'est un projet essentiellement à l'abandon.

    • [^] # Re: Bazaar maintenu ?

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 13 mai 2016 à 11:21.

      Les coulisses :

      1. j'ai pris la liste des DVCS libres hormis Git sur Wikipédia (« ArX (2003) Codeville (2005) Darcs (2002) DCVS (2002) Fossil (2007) GNU arch (2001) GNU Bazaar (2005) Mercurial (2005) Monotone (2003) SVK (2003) Veracity (2010) »)
      2. j'ai retiré ceux marqué « Unmaintained » or « Abandoned » or « Discontinued » or « deprecation » sur Wikipédia (ArX, Codeville, DCVS, GNU arch, SVK).
      3. Parmi les restants, les noms de Monotone et Veracity ne m'étaient pas familiers et leurs dernières versions semblaient anciennes.
      4. Ceux qui restent (Darcs, Mercurial, Bazaar ou Fossil) ont sorti des versions fin 2015 ou début 2016, donc sont encore maintenus (qu'ils soient largement utilisés ou non, qu'ils soient mourants ou non).
  • # Sécurité de BitKeeper

    Posté par  . Évalué à 10.

    À voir sur http://www.openwall.com/lists/oss-security/2016/05/10/5

    En gros, y a des failles de partout, et ils s'en foutent un peu, parce que BitKeeper n'est installé que derrière des pare-feux, avec des utilisateurs de confiances.

    Ça ne plaît pas trop aux développeurs Debian qui ont bien discuté de ça dans l'hypothèse de l'intégration de BitKeeper à Debian (Cf https://lists.debian.org/debian-devel/2016/05/msg00177.html et la suite).

  • # Recul

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Merci pour le liens, c'est assez amusant de lire les commentaires de l'époque avec plus de 10 ans de recul. Certains avaient vu juste. C'est aussi amusant de lire des questions sur « à quoi ça sert », « est-ce que c'est vraiment un SCM ? », des questions tout à fait compréhensible en 2005.

    C'est quand même très impressionnant d'avoir eu un truc fonctionnel en 1 semaine.

    • [^] # Re: Recul

      Posté par  . Évalué à 0.

      des questions tout à fait compréhensible en 2005

      CVS date de 1990 et il n'était pas le premier sur le marché, donc a moins de sortir de l'école ou de ne pas connaitre l'abréviation ce genre de logiciel était largement utilisé. «compréhensible» n'est peut être pas le terme adapté.

      • [^] # Re: Recul

        Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 13 mai 2016 à 10:16.

        Non, ce qui n'était pas (bien) connu c'était les outils décentralisés, et surtout ce que Git était et ce qu'il faisait. Dans la plupart des commentaires la notion de SCM semble tout à fait maîtrisée.

        P.-S.: en relisant mon précédent commentaire je pense que tu as mal lu, la question est « est-ce que c'est vraiment un SCM ? » et non pas « qu'est-ce qu'un SCM ? »

        • [^] # Re: Recul

          Posté par  . Évalué à 2.

          En effet désolé pour ce quiproquo

      • [^] # Re: Recul

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

        N'oublions pas qu'il existe un outil dans le standard POSIX: SCCS.

        http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sccs.html

        Cela dit, je n'ai jamais vu personne l'utiliser, pour le moment.

        • [^] # Re: Recul

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

          lol

          y toucher c'est vouloir l'oublier tout de suite.

          mais cela n'engage que moi, et mes souvenirs datent du millénaire précédant.

        • [^] # Re: Recul

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

          Je l'ai utilisé de 1990 à 2002. C'est assez limité. L'intérêt de ce logiciel est de stocker tout l'historique d'un fichier dans un seul fichier en ne stockant que les deltas d'une version à l'autre. On a ensuite la possibilité d'extraire une version particulière ou de voir les différences entre deux versions.

      • [^] # Re: Recul

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

        J'imagine que je ne suis pas le seul ici à connaître plusieurs entreprises qui n'utilisent pas de SCM du tout (décentralisé ou pas), parce qu'elles ne savent pas que ça existe ou ne savent pas vraiment à quoi ça sert. Celles que je connais sont de petites boîtes faisant des logiciels propriétaires.

        Ça me fait froid dans le dos rien que d'y repenser :)

        • [^] # Re: Recul

          Posté par  . Évalué à 2.

          Je dirais même que la majorité des petites boîtes n'utilisent pas de SCM pour leurs développements. Que ce soient de petits éditeurs, ou des programmes pour leurs besoins propres.

    • [^] # Re: Recul

      Posté par  . Évalué à 10.

      Certains avaient vu juste.

      Ou pas
      https://linuxfr.org/nodes/18022/comments/559871

      • [^] # Re: Recul

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 14 mai 2016 à 19:53.

        Excellent !
        Pauvre pBpG, foirer à ce point une prédiction c'est presque du grand art. À sa décharge il faut dire que le succès de Git était difficile à anticiper.

        • [^] # Re: Recul

          Posté par  . Évalué à 5.

          Il y a quelques perles dans ce journal :

          Alors maintenant qu'il reparte dans une implementation d'un simili-SCM-tronqué dont on peut douter de la durée de vie, ca me derange pas du tout. Il est libre de faire ce que bon lui semble. Par contre, qu'il chippe les forces de dév en attirant des gens sur un projet à la durée de vie contestable (solution de rechange d'après ses dires), et dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
          http://linuxfr.org/news/linus-d%C3%A9veloppe-un-rempla%C3%A7ant-original-%C3%A0-bitkeeper#comment-560114

          Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre.

  • # BitKeeper comme une source d'inspiration

    Posté par  . Évalué à 10.

    Ce que l'on sait, c'est que cet épisode à débouché sur la naissance de Git et d'un foisonnement d'alternatives plus ou moins heureuses.

    Ce que l'on sait déjà moins, c'est que le comportement de son auteur a aussi été source d'inspiration pour baptiser certains d'entre eux.

    Git d'abord, même si Linus s'en défendait en prétendant que ça ne s'adressait qu'à lui:

    Torvalds seemed aware that his decision to drop BitKeeper would also be controversial. When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."

    Ca reste suffisamment ambigu pour laisser le champ à une autre interprétation, tout en lui évitant un procès en diffamation (on ne saura jamais).

    Par contre lorsqu'on pense à Mercurial, on ne voit pas bien le rapport.
    Le mercure, son symbole Hg en guise de commande ???

    Que nous apprend la traduction de mercurial ?
    Tiens, il existe un autre sens: "d'humeur changeante, inégale, versatile".

    Quand même, Matt Mackal, son auteur n'aurait pas pensé à ça ?

    Et bien si:

    Shortly before the first release, I read an article about the ongoing
    Bitkeeper debacle that described Larry McVoy as mercurial (in the sense
    of 'fickle'). Given the multiple meanings, the convenient abbreviation,
    and the good fit with my pre-existing naming scheme (see my email
    address), it clicked instantly. Mercurial is thus named in Larry's
    honor. I do not know if the same is true of Git.

    A coté de ça, les jeux de mots à double sens autour de du contrôle de "version" semblent presque fadasses:
    Même le "subversif" svn qui voulait enterrer Concurrent Version System, ou encore son contrepied défunt superversion et autres veracity, …

    Thanks to you Larry !

  • # Commentaire supprimé

    Posté par  . Évalué à -10.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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