Q: Depuis combien de temps développes-tu ? A: Je développe depuis 40 ans. Dans le contexte des forges, j'utilise des forges depuis leur création, c'est à dire 2000. Q: Dans le cadre de ton travail rémunéré, combien de temps passes-tu à développer ? A: 100% du temps. Q: Développes-tu en dehors de ton temps de travail ? A: Oui, beaucoup. Dans ce cadre là, le développement représente en moyenne au minimum 50% du temps. Q: En tant que développeur de logiciel libre, quel est ton quotidien ? A: Cela commence par quelque chose à implémenter, que ce soit un bugfix ou une feature. L'origine de cette demande là est, dans le cas d'une feature: - dans le passé, mon imagination seulement - maintenant j'essaie de me discipliner pour que cela vienne de recherche utilisateur, c'est à dire ce pourquoi les utilisateurs ont exprimé un besoin. Dans le cas d'un bugfix, la provenance de cette demande vient de la manifestation d'un bug. Dans les deux cas cela se traduit par une modification d'un logiciel existant, très exceptionnellement la création d'un logiciel. Cette modification est stockée dans un DVCS. Ce commit est associé à une discussion sur la façon de fabriquer ce commit. Cette discussion peut être très succincte et être dans le message de commit ou elle peut être beaucoup plus étendue et être dans un issue tracker ou bien dans un forum où il s'agit de discuter soit avec d'autres développeurs, soit avec d’autres utilisateurs pour essayer de cerner la meilleure façon d'implémenter la feature ou de corriger le bug. C'est à l'issue de cette discussion que le commit va maturer. Il y a un espèce de couple entre discussion et traduction en commit. Une fois que ce commit est produit et que la discussion a abouti il y a une discussion sur l'implémentation elle-même qui est un processus de review où il s'agit de discuter de la bonne façon de faire et des mérites techniques du commit (qu'il est sain, qu'il s'intègre bien à la base de code) - c'est un peu différent de la discussion préliminaire. À l’issue de cette discussion là, une tierce personne fusionne/merge ce commit dans la base de code du logiciel. Ce cycle de reviews, de discussions et de merge est accompagné d'un robot qui procède à des vérifications qui sont des tests unitaires, d'intégration. Ces tests sont déclenchés soit par une CI, soit manuellement. Ces tests sont toujours présents: tout code doit être accompagné d'un test. Une fois que le morceau de logiciel est intégré dans la base de code: il fait partie d'une release. Le processus de release revient à dire: à ce point dans le code, on va faire l'effort de le mettre à disposition des utilisateurs qui n'ont pas la capacité ou l'envie d'utiliser le logiciel à partir de la base de code elle même. Ce processus peut inclure du packaging ou simplement le fait d'être intégré dans une base de code plus grande, de façon à ce que des utilisateurs - qu'ils soient experts ou non - puissent en disposer dans leur environnement préféré, dans leur distribution. Cela peut être un paquet Debian, un paquet PyPI. La dernière étape du cycle de vie concerne les releases stables: à partir du moment où le logiciel est packagé/releasé pour les utilisateurs il peut aussi commencer une vie où il n'est plus question d'intégrer de nouvelle feature mais il est plutôt question de corriger les bugs sur les versions stables et s'assurer qu'il n'y a pas de trou de sécurité et sans rajouter la moindre feature. Cela représente des cycles de vie d'une même base de code dans des contextes différents et le plus fréquent de ces cyles de vie, qui n'est pas celui du développement, c'est celui des releases stables qui n'ont pas de feature associée. Q: Comment fournis-tu ces contributions ? A: À travers des releases du logiciel dans différents contextes. Q: Comment gères-tu les dépendances ? A: Tout logiciel libre est pétri de dépendances, il y a de nombreuses dépendances. Cela dépend des contextes, il y a essentiellement deux modes: - soit c'est une dépendance qui est une dépendance au moment de la distribution ou au moment de l'installation. Ce type de dépendance se manifeste par la désignation d'un package dépendant et d'un numéro de version ou des contraintes de version. Par exemple sur PyPI je vais indiquer qu’une dépendance sur requests dans telle version exactement et au moment de l'installation c'est cette dépendance qui sera installée mais l'expression de cette dépendance se trouve dans le logiciel lui-même. - soit le logiciel est intégré à la base de code. Cela peut se produire quand un logiciel n'est pas ou plus maintenu. À ce moment là, plutôt que de dépendre d'une source externe on préfère le copier à l'intérieur de la base de code. Q: Qu'est ce qui compose un projet logiciel ? A: Un projet qui est sur une forge n'est pas juste composé de la base de code. Si je devais sauvegarder un logiciel et le garder en l'état, avec tout ce qui permet de travailler dessus, de le prendre en main, il faudrait que je sauvegarde: - la base de code - les issues - toutes les releases qui ont été faites et communiquées - les discussions concernant ce logiciel dans différents contextes, cela peut permettre de comprendre comment un commit est fait - tout ce qui concerne la CI et la façon de la mettre en œuvre: l'intégralité de ce qui permet à la CI de fonctionner (pas seulement le résultat de la CI) Tous ces éléments constituent le projet, le projet n'est pas juste composé de la base de code. Q: La perte des discussions concernant le logiciel aurait un impact négatif sur les développements futurs ? A: Oui, beaucoup. On perdrait de l'histoire, on ne pourrait pas comprendre le présent, certains bugs ni pourquoi certains morceaux de code ont été faits. On est handicapé à corriger des bugs. Q: Sur quels projets logiciels travailles-tu en ce moment ? A: En ce moment je travaille sur le projet qui est un logiciel de stockage. Q: Quelles forges utilises-tu ? A: Le projet utilise deux forges de façon complémentaire: Redmine (pour les issues et tout le processus de release management) et GitHub (pour le code uniquement). Les reviews se font sur GitHub. J'ai à peu près tout utilisé (sourceforge, savannah, gogs, gitea, gitlab, fossil). Pour les forges qui sont autohébergées, j'ai utilisé des dizaines d'instance différentes. J'ai aussi utilisé GitHub pendant des années, jusqu'à fermer mon compte il y a 3 ans. Q: Quel projet logiciel utilise plusieurs forges ? A: utilise deux forges Q: Les dépendances de sont-elles toutes hébergées sur la même forge ? A: Non, a énormément de dépendance. Certaines sont hébergées sur d'autres forges. Une partie du code de sur lequel j'ai beaucoup travaillé () était hébergée au moment où j'y travaillais sur une instance de GitLab. Le problème que j'avais en travaillant à la fois sur dans GitHub et sur une instance GitLab était d'arriver à faire le lien entre les deux. Quand il y avait un bug sur qui impactait , j'étais obligé d'ouvrir une issue sur le GitLab de et de garder trace dans le Redmine de du lien vers cette issue. Par ailleurs il fallait manuellement faire le lien entre GitHub et Redmine pour indiquer à quelle issue Redmine correspondait telle pull-request. Il n'y a aucun tooling particulier, ni dans GitHub ni dans Redmine, pour arriver à maintenir ce genre de dépendance qui pourrait être un champ permettant de dire "telle issue redmine correspond à telle issue github" ou sur GitLab "voila le lien vers cette issue Redmine dont le projet dépend". Je n'avais aucune notification sur le fait que quand quelque chose se passait sur , cela pouvait avoir un impact sur Redmine: c'était à moi d'aller lire les commentaires de l'issue sur le GitLab de pour savoir si cela avait un impact sur (et vice versa). La situation que j'ai décrite est celle d'il y a 4 ans mais aujourd'hui je ne crois pas qu'il y ait plus de lien entre GitLab et Redmine ni entre GitLab et GitHub. 1. Maintenant je travaille sur les releases stables du projet , cela consiste à travailler sur les backports. Quand un bug est fixé sur la branche master, le développeur qui l'a fixé indique uniquement dans quelles branches stables ce commit devrait être ajouté. Le travail de backporteur consiste à être notifié dans Redmine, je vais alors faire un cherry-pick des commits qui vont bien, résoudre les conflits éventuels. Je suis ensuite coincé car je ne peux pas les uploader sur GitHub: je ne peux donc pas faire ce travail là puisque je n'ai pas de compte GitHub. Jusqu'à il y a un an ou deux, le projet acceptait des contributions par mail (comme pour le noyau Linux) mais le projet a arrêté ce fonctionnement. Comme je ne peux pas faire cette activité la, je me cantonne à l'analyse des problèmes liés aux backports. Ces analyses peuvent parfois demander beaucoup de travail. Par exemple je peux noter dans l'issue Redmine les commits nécessaires à un backport. 2. Une autre contribution que je peux faire: quand quelqu'un fait un backport (une pull request sur GitHub), un script va chercher les pull-requests GitHub via l'API publique (ce script ne nécessite pas de compte GitHub). Le script permet de faire le lien entre GitHub et Redmine, cela m'indique si un ticket peut être fermé, quand par exemple une pull request est mergée mais que le développeur a oublié de fermer l'issue Redmine. 3. Il y a une 3ème contribution que je fais: j'analyse les erreurs de CI sur les pull-requests liées aux backports. Les sorties d'erreur sont énormes et assez difficiles à analyser, on peut passer des heures à fouiller dans ces logs pour trouver l'origine de l'erreur. Dans l'issue Redmine je rajoute mon analyse de l'erreur afin d'aider la personne qui a fait la pull request à corriger son code. Q: Comment es-tu notifié de l'activité d'un projet hébergé sur une forge ? A: Je suis obligé d'avoir un compte afin d'utiliser les mécanismes de notification de la forge. Il faut donc un compte sur chaque forge. Q: Comment suis-tu les releases de ? Et comment suis-tu les patchs auxquels tu as contribué ? A: Je suis les releases parce que je suis acteur actif là-dessus, j'ai le nez dessus. Je suis abonné à tous les tickets Redmine. Si il y a une discussion sur GitHub je ne suis pas au courant et il n'y a pas d'écho dans Redmine: il faut que j'aille manuellement voir et je peux rater des trucs. Q: Comment communiques-tu avec les utilisateurs de la forge ? A: Je ne peux pas communiquer avec les utilisateurs de GitHub. C'est l'enfer parce que GitHub ne révèle pas le courriel, la plupart des utilisateurs ne le révèle pas non plus. La plupart des gens n'ont pas de lien vers une autre page sur laquelle un courriel serait mentionné. Ils n'utilisent même pas le même nick sur GitHub et sur IRC ou sur Redmine. Dans le projet je connais pas mal de gens et j'ai ce mapping en tête, mais quand une nouvelle personne arrive, je suis obligé de demander à quelqu'un d'envoyer un message privé via GitHub mais n'ayant pas de compte sur GitHub, je suis coincé: cela m'arrive régulièrement. Les emails sont disponibles dans les messages de commit mais ils ne sont pas affichés par l'interface web et un utilisateur peut discuter sur GitHub sans avoir de commit. Le cas le plus fréquent: je vois quelqu'un qui n'est pas l'auteur d'une pull request qui participe à la discussion. Je sais que c'est quelqu'un qui fait partie du projet et je me demande si cette personne a fait des commits: j'essaie de savoir si c'est un contributeur ou une contributrice ou pas. À ce moment là j'ai son nick GitHub, je n'ai pas son mail. Il faudrait que j'aille fouiller sur GitHub son historique de contribution jusqu'à remonter à un commit sur GitHub pour arriver à le trouver. Ce n'est pas pratique. La dernière fois que cela c'est produit, il y a deux semaines, c'est une personne de qui avait beaucoup participé à une discussion sur GitHub concernant un sujet technique très particulier sans être contributeur. J'ai du demander à quelqu'un de communiquer avec lui via GitHub pour lui demander son adresse email. Q: Gères-tu des mirroirs de projet logiciel ? A: Oui, par exemple sur fedeproxy.eu j'ai une copie du contenu du dépôt Git du projet . Cela me permet de gérer les modifications que je veux faire, de gérer des branches pour bosser sur sans que cela soit juste sur ma machine. J'aimerais que cela soit un mirroir mais ce n'est pas le cas parce que GitLab (Community Edition) ne dispose pas de la fonctionnalité permettant de se synchroniser avec un projet extérieur en allant tirer les derniers commits d'une arborescence. Q: As-tu déjà utilisé la fonctionnalité d'import/export d'une forge ? A: Oui, j'ai commencé à le faire en 2000 avec sourceforge. Cela n'a jamais marché à satisfaction. Je l'ai utilisé quelques fois pour exporter le projet qui est une librairie C depuis sourceforge vers Savannah. Cet export incluait un peu plus de choses que juste le dépôt de code qui était sous subversion mais je ne me rappelle plus exactement quoi. Je crois que l'export contenait aussi les issues mais pas toutes: c'était un export partiellement fonctionnel que je n'ai fait qu'une fois. L'objectif était de quitter sourceforge pour utiliser Savannah. Les personnes qui travaillaient sur ce projet là n'ont pas été notifiées, c'était un projet avec très peu d'audience - j'ai peut être posté un message pour dire que le projet était migré et puis voila. J'ai fait un autre export de projet qui a consisté à sortir de GitHub pour aller sur une instance autohébergée de GitLab. C'était dans le cadre du projet quand j'ai commencé à travailler sur . J'ai commencé à travailler sur GitHub pour ce projet, mais comme il était relativement indépendant, j'ai eu envie de l'extraire de GitHub et là je n'ai pas utilisé la fonction d'import/export. Pour avoir regardé récemment la fonction d'export de GitHub n'aurait pas convenu parce que à l'époque il n'existait pas de fonction d'import de projet GitHub dans GitLab. C'est quelque chose qui existe aujourd'hui, en mode oneshot. Il y a cependant des limitations: l'import d'un projet GitHub dans GitLab n'exporte pas tout - cela exporte pas mal de choses - en tout cas c'est un oneshot. Q: Qu'est ce qui a motivé ces deux migrations (vers Savannah et vers GitLab) ? A: Dans les deux cas c'était une motivation éthique, c'est à dire que je désapprouvais les pratiques de centralisation de GitHub et le fait que GitHub est un logiciel propriétaire qu'on ne peut pas autohéberger. Q: Les projets originaux ont-ils été conservés ? A: Non Q: En ce qui concerne , les utilisateurs ont-ils suivi ? A: Oui, j'ai été les chercher les un après les autres pour leur demander de se créer un compte. Il y en avait 3, cela a pris plusieurs semaines de les convaincre de se créer un compte sur une autre forge. Q: Les données qui ont été perdues sont celles relatives aux discussions ? A: Oui, les discussions qui ont pu avoir lieu sur l'ancienne forge ont été perdues. Q: As-tu entièrement perdu des projets parce qu’un service de forge a été arrêté ? A: Non, je n'ai pas perdu de projet. Je connais des gens qui en ont perdu. Sur la forge gna.org où il y avait ~1000 projets, moi j'en avais et je ne les ai pas perdu parce que j'avais une copie. Par contre il y avait des gens qui au moment où la forge a été arrêtée en 2017, bien qu'il y ait eu un an de préavis, des mails à répétitions, des annonces et qu'il y a eu ensuite 6 mois de moratoire où des copies étaient envoyées aux gens qui en réclamaient. Malgré ça il y a des gens qui se sont réveillés deux ans après: ils l'avaient laissé sur la forge et puis ils l'ont perdu parce qu'ils étaient à un moment de leur vie où ils ne s'intéressaient pas au sujet et en revenant plusieurs années plus tard ils se sont rendu compte que leur projet était perdu. Ce n'est pas ce qui m'est arrivé. Du côté de la visibilité publique d'un projet, il y en a un en particulier, - un logiciel sur lequel j'ai travaillé au début des années 2000 -  que j'autohébergeais sur une forge, qui existe toujours sur mes disques mais qui n'a plus d'existence publique: les données ne sont pas perdues mais elles sont inaccessibles au monde extérieur. Je n'ai pas migré ce projet sur une autre forge. Q: Quelles sont les forges que tu as choisi de ne pas utiliser ? A: GitHub. Il y a trois ans j'ai décidé de fermer mon compte pour protester contre la politique de brevets logiciels de Microsoft qui est le propriétaire de GitHub. Microsoft détient et fait la promotion des brevets logiciels qui sont toxiques pour le logiciel libre. C'est la raison principale de mon boycott. La raison secondaire est que c'est un logiciel propriétaire qui maintient les utilisateurs captifs et qui est conçu pour. Q: Quelles sont les forges que tu n'utilises pas à moins d'être obligé de le faire ? A: gitlab.com parce que c'est un logiciel propriétaire. Comme je suis très habitué de GitLab, je l'utilise en faisant bien attention de n'utiliser que les fonctionnalités dont je sais qu'elles sont disponibles dans la version libre. Par exemple jamais je n'irais sur GitLab pour pouvoir faire un mirroir synchronisé d'un projet GitHub parce que je sais que c'est une fonctionnalité qui n'existe que dans la version propriétaire. Q: Quelle est ta forge préférée ? A: Aujourd'hui c'est la version libre de GitLab. Comme je n'aime pas le modèle économique de la société qui développe GitLab, j'aimerais pouvoir me tourner vers Gitea qui a un modèle qui me plaît plus. Si j'avais à faire le choix aujourd'hui, je tenterai Gitea en essayant d'ignorer que peut être c'est moins bien fonctionnellement - juste parce que je préfère l'éthique - mais aujourd'hui j'ai une grosse habitude d'utiliser GitLab donc ça me prendrait du temps de m'extraire de GitLab. Q: As-tu participé au développement d'un projet sans utiliser la forge sur laquelle il est hébergé ? A: Oui, . C'est très difficile de contribuer du code mais j'ai rajouté un patch dans une issue sur un point très particulier et quelqu'un a récupéré ce patch là et en a fait une pull request - c'est anecdotique. Q: Connais-tu des personnes qui contribuent à un projet sans utiliser la forge sur laquelle le projet est hébergé ? A: Non. Je connais une personne qui contribue au noyau Linux et cette personne envoie des patchs par mail. J'ai contribué un patch à Qemu qui est un autre projet qui n'a pas de forge mais une liste de diffusion pour recevoir les patchs. Q: Connais-tu des forges qui excluent des utilisateurs en fonction de là où ils vivent ? A: Oui: GitHub qui exclut toutes les personnes qui habitent dans des pays qui sont sous embargo du gouvernement US. Cela a fait l'actualité il n'y a pas si longtemps quand un projet a été fermé parce qu'un des développeurs s'était connecté depuis l'Iran. Cela a duré 48h ou 72h. Q: Utilises-tu des robots pour interagir avec un projet hébergé sur une forge ? A: Oui, beaucoup. Au moment où j'avais encore un compte GitHub, j'avais développé un logiciel qui s'appelait . C'était un logiciel en ligne de commande qui avait pour objectif d'automatiser certains taches manuelles en utilisant l'API GitHub et l'API Redmine de façon à faire des travaux qui concernaient les releases stable par exemple. Le logiciel utilisait l'API et je l'utilisais quotidiennement. Aujourd'hui ce logiciel n'existe plus, il y a des morceaux de ce logiciel qui ont été transformés en scripts. Ce que j'utilise actuellement avec les releases stables et qui interagit avec Redmine, c'est des scripts qui ont le même fonctionnement. Q: As-tu écrit des tests d'intégration pour le projet ? A: J'avais écrit des tests d’intégration qui lançaient une instance de Redmine et j'avais créé un compte dédié sur GitHub parce que je n'avais pas la possibilité de lancer une instance de GitHub localement. La disponibilité de l'API GitHub était plus que moyenne: cela cassait régulièrement, en plus l'API changeait, l'effort de maintenance était pénible. Q: Connais-tu des outils qui permettent d'effectuer des opérations identiques sur plusieurs forges ? A: Oui, je n'en connais qu'un c'est Zuul qui sait interagir avec GitLab et GitHub et qui fournit un service de CI. Q: Comment suis-tu l'activité des forks d'un projet ? A: Je fais ça manuellement. Q: Comment merges-tu une proposition de modification qui est dans un fork ? A: Je vais chercher la branche Git du fork, je la mets dans un fork local et je fais manuellement une merge request pour proposer la modification: il n'y a pas vraiment de lien avec le fork initial. L'auteur du commit reste inchangé mais la provenance est perdue. Q: À qui as-tu besoin de faire confiance concernant l'intégrité du logiciel que tu publies ? A: Si je publie un logiciel sur une forge, les gens qui vont aller le chercher doivent faire confiance à la forge pour donner le logiciel que j'ai publié. Je dois donc faire confiance à la forge. Q: Signes-tu tes commits ? A: Oui, toujours. Q: Comment vérifies-tu que tes commits n'ont pas été réécrits ? A: En vérifiant la signature. La forge affiche si un commit est signé et la validité de la signature. Q: As-tu connaissance de collisions SHA1 ? Comment cette vulnérabilité permettrait de réécrire l'historique d'un dépôt ? A: Oui. L'augmentation de la capacité des ordinateurs fait que depuis quelques années on arrive à créer le document que l'on veut avec le contenu que l'on veut qui a le même SHA1 qu'un commit existant. On pourrait remplacer un commit par un autre avec le même SHA1 mais avec un contenu différent et donc injecter du code dans une base de code - cela nécessite une capacité de calcul importante, GitHub avait cette capacité de calcul. Git transitionne vers SHA256. Q: Imagine que tu aies une baguette magique qui te permette d’interagir avec plusieurs forges pour un projet donné. Que ferais-tu avec cette baguette magique ? A: Je ferai en sorte qu'à travers un standard indépendant il soit possible d'utiliser une forge et de participer (dans tous ses aspects) à un projet libre qui est sur une autre forge, sans qu'il n'y ait aucune adhérence a une forge particulière - comme on peut envoyer un courriel depuis Outlook et le lire sur Thunderbird. Q: Quelque chose fonctionne-t-il correctement quand tu travailles avec plusieurs forges sur un projet ? A: Non