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 !
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
- Site web de Bitkeeper (263 clics)
- Annonce du passage en Open Source de BitKeeper (117 clics)
- Pourquoi passer à BitKeeper ? (198 clics)
- Clonez BitKeeper avec Git ;-) (140 clics)
- Site officiel de Git (99 clics)
- LinuxFr.org : BitKeeper, RMS et PLONK. (164 clics)
- LinuxFr.org : BitKeeper : plus de version gratuite (130 clics)
- LinuxFr.org : La réaction de Richard Stallman aux récents évènements autour de BitKeeper (249 clics)
- LinuxFr.org : Linus développe un remplaçant original à BitKeeper (219 clics)
- LinuxFr.org : Le développement du noyau continue autour de Git (139 clics)
- Wikipedia: Comparison of version control software (132 clics)
# Quelques explications sur la raison du passage en open-source
Posté par Matthieu Moy (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 Maclag . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 9.
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.
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.
[^] # Re: Quelques explications sur la raison du passage en open-source
Posté par fasthm . Évalué à 10.
En même temps on ne tombe pas tous les jours sur un concurrent du calibre de Linus Torvalds :-)
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Quelques explications sur la raison du passage en open-source
Posté par Philip Marlowe . Évalué à 10.
Ni, auparavant, sur un utilisateur du même calibre.
[^] # Re: Quelques explications sur la raison du passage en open-source
Posté par groumly . Évalué à 10.
Tres tres comique quand même, venant d'un gars qui trolle à longueur de journée sur le fait que le libre, c'est une licence, point à la ligne, pas une philosophie qui n'existe que dans la tête des libristes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Incroyable
Posté par MTux . É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 :
Il n'existait pas déjà cvs ou svn à cette époque ?
[^] # Re: Incroyable
Posté par laurentb (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 Blackknight (site web personnel, Mastodon) . Évalué à 5.
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 Vincent Bernat (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 Zenitram (site web personnel) . Évalué à 7.
tu oses sérieusement comparer CVS/SVN à Git?
Tu es donc jeune et n'a jamais eu à utiliser CVS/SVN sur un gros projet décentralisé…
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 MTux . Évalué à 3. Dernière modification le 13 mai 2016 à 10:08.
FreeBSD utilise svn et OpenBSD cvs non ? C'est ce que je vois après une rapide vérification.
Pourquoi pas Linux alors ?
Je suis utilisateur "basique" de git, dans une époque où github est devenu plus ou moins un réseau social.
[^] # Re: Incroyable
Posté par Renault (site web personnel) . Évalué à 10.
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 claudex . Évalué à 8.
Il suffit de voir le temps mis par un
cvs uppour 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 Florent Zara (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 claudex . Évalué à 7.
[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 reno . Évalué à 1.
Gérer le kernel avec cvs??
Tu es sérieux là?
svn je connais moins.
[^] # Re: Incroyable
Posté par DerekSagan . Évalué à 5.
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
Aussi nul que cvs, mais sans beaucoup de ses bugs.
[^] # Re: Incroyable
Posté par lolop (site web personnel) . Évalué à 9.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Incroyable
Posté par Moonz . É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 Pierre Jarillon (site web personnel) . Évalué à 4.
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 DerekSagan . É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 chimrod (site web personnel) . Évalué à 10.
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 DerekSagan . É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 Matthieu Moy (site web personnel) . Évalué à 10.
Justement non. En gros, un
cvs commitsur 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 DerekSagan . É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 El Titi . É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.
```
[^] # Re: Incroyable
Posté par El Titi . Évalué à 4.
Remontons dans le temps:
Les premières version du wiki revctrl datant de 2005
http://web.archive.org/web/20051119112229/http://revctrl.org/
Ca vous laisse une bel aperçu des outils mais aussi de tous les phosphore dépensé autour des algos de merge:
http://web.archive.org/web/20051217192502/http://revctrl.org/CategoryMergeAlgorithm
Et là Git débarque avec son heuristique et basé sur le contenu et ses stratégies de merge épurées (ou éculées ?) … et remporte la mise.
[^] # Re: Incroyable
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Par moment, je me demande si Git n'a pas fonctionné en partie grâce au culte de la personnalité autour de Linus Torvalds.
Il y avait déjà de bons outils à l'époque mais, bien entendu, il n'y a pas de meilleur outil que celui que l'on fait soi-même… :)
[^] # Re: Incroyable
Posté par jeberger (site web personnel) . Évalué à 5.
C'est d'ailleurs plus ou moins confirmé quand on regarde les arguments avancés par ceux qui expliquent pourquoi ils ont choisi Git ou Mercurial.
Raisons généralement avancées pour choisir Git plutôt que Mercurial :
Raisons généralement avancées pour choisir Mercurial plutôt que Git :
PS : le Trolldi, c'est permis ;)
[^] # Re: Incroyable
Posté par El Titi . Évalué à 7.
Et pour ceux que ça intéresserait, je vous ai également retrouvé la référence (hormis wikipedia) en terme de comparaison d'outils à cette époque
https://web.archive.org/web/20050403040438/http://better-scm.berlios.de/comparison/comparison.html
Et pour vous faire une idée la première version incluant Git:
https://web.archive.org/web/20080513074801/http://better-scm.berlios.de/comparison/comparison.html
# Bazaar maintenu ?
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
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 Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 13 mai 2016 à 11:21.
Les coulisses :
[^] # Re: Bazaar maintenu ?
Posté par El Titi . Évalué à 4.
Et pourtant, quelqu'un que tu dois connaître s'était fendu d'une dépêche ;-)
https://linuxfr.org/news/veracity-un-nouveau-gestionnaire-de-versions-d%C3%A9centralis%C3%A9
[^] # Re: Bazaar maintenu ?
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Bah, moi aussi, je l'avais oublié !
# Sécurité de BitKeeper
Posté par Glandos . É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 Goffi (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 Mimoza . Évalué à 0.
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 Goffi (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 Mimoza . Évalué à 2.
En effet désolé pour ce quiproquo
[^] # Re: Recul
Posté par pulkomandy (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 SauronDeMordor (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 Pierre Jarillon (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 GuieA_7 (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 Kerro . É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 El Titi . Évalué à 10.
Ou pas
https://linuxfr.org/nodes/18022/comments/559871
[^] # Re: Recul
Posté par patrick_g (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 Faya . Évalué à 5.
Il y a quelques perles dans ce journal :
# BitKeeper comme une source d'inspiration
Posté par El Titi . É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:
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:
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 !
[^] # Re: BitKeeper comme une source d'inspiration
Posté par El Titi . Évalué à 4.
Et lui-même prend ça avec philosophie:
https://news.ycombinator.com/item?id=11668717
[^] # Re: BitKeeper comme une source d'inspiration
Posté par djano . Évalué à 2.
À noter qu'il existe "Subversive": un plugin pour Eclipse qui est un client pour "Subversion" :)
# Commentaire supprimé
Posté par Anonyme . É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.