*Note: travaillant chez [Cliss XXI](https://www.cliss21.com) depuis 2018, le « on » se réfère souvent à ce contexte de travail. L'essentiel de nos projets sont des projets d'appli web Python/Django souvent avec du Wagtail.*

Q: Depuis combien de temps développes-tu ?
A: Professionnellement depuis 2012. Non professionnellement depuis 2009 à peu près. Avant j'ai à peu près toujours rédigé du code mais ça n'a pas été une activité qui dominait mon temps ou ça n'a pas été des gros codes.

Q: Qu'est ce que tu entends par gros code ?
A: Un truc qui nécessite d'avoir à utiliser un gestionnaire de versions. J'ai démarré l'informatique vers l'âge de 9 ou 10 ans, à l'époque j'ai appris avec un basic Amstrad CPC et puis le gros pavé manuel qui était livré avec et je faisais des petits codes. J'ai fait du développement dans un contexte scolaire vu que j'étais ingénieur mais ce n'est pas des trucs que je considère sérieux. Les codes sérieux j'ai commencé à les faire il y a 15 ans. J'ai commencé à faire du cpold et puis j'ai rapidement découvert d'autres façons de faire.

Q: Tu développes à la fois professionnellement et aussi sur ton temps libre ?
A: Oui

Q: Professionnellement, quel pourcentage de ton temps passes-tu à développer ? Est ce que c'est ton activité exclusive ?
A: Une petite moitié du temps

Q: Est ce que tu pourrais décrire dans les grandes lignes, quand tu travailles sur un projet logiciel, quelle est ta routine ? Comment ça se passe ? Quelles sont tes activités de cycle de développement ?
A: Ça dépend. On est plutôt sur des petits projets dans notre activité. On fait un peu tout et pas forcément tout bien mais on fait un peu tout. En amont du développement il va falloir étudier un peu le besoin des utilisateurs. C'est très souvent très difficile d'obtenir le besoin de l'utilisateur qui ne soit pas un fantasme. En plus quand on fait du développement on a une capacité très limitée à anticiper les vrais difficultés. J'essaie de découper en bouquet de fonctionnalités les projets. J'essaie d'avancer bouquet après bouquet. On attend de livrer/finaliser un petit peu un bouquet avant de passer à un autre et puis on fait ça dans la durée. J'ai rarement une situation où j'ai fait 20 jours de développement consécutif et où ensuite j'essaie d'avoir le retour de l'usager : en général ce n'est pas ça qu'on fait, c'est plutôt des salves de 2 ou 3 jours. J'ai déjà essayé de faire des users stories mais ça ne fonctionne pas avec les gens avec qui on a affaire. Le mieux c'est d'essayer de comprendre leurs besoins : c'est là qu'on est le plus fort, c'est quand on partage un besoin avec eux.

Q: Ce besoin là tu le traduis en code à un moment donné ?
A: Tout à fait, là j'étais plutôt à discuter sur le projet. Au niveau code je fais beaucoup du baby step, donc ça dépend. En fait je développe beaucoup en Python et j'aime beaucoup jouer avec l'interpréteur Python avant d'inscrire dans le marbre une partie de code. Je mets souvent au point les parties « intelligentes » dans l'interpréteur.

Q: Où est ce que tu stockes ce code là ? Sur ta machine ?
A: Oui, usuellement je travaille sur ma machine.

Q: Et comment tu le partages avec ton client ?
A: En général, le client ne regarde pas le code, donc je déploie une préprod ou une prod.

Q: En copiant le code directement sur les machines ?
A: Non, nous le cycle normal c'est de passer par la forge : on déploie en tirant sur la forge.

Q: Et comment ça se passe dans ce cadre là ? Tu pousses ton code sur la forge ?

A: Oui. En fonction de la maturité du sujet, on va pousser le code, éventuellement on va pousser une série de révisions et puis faire une pull request qui va être relue après. On a un cookiecutter donc on instancie tous nos projets à partir d'une base commune. Coté prod, la façon normale de déployer c'est `git pull` et `make update`. Le `make update` va mettre à jour ou initialiser le `virtualenv` et puis il va appliquer les migrations. Il va notifier le serveur d'application que le code a changé.

Q: Comment tu gères les dépendances ? C'est du python, j'imagine que tu fais un pip install ?
A: Oui, tout à fait, avec un fichier requirements.txt.

Q: Une question un peu plus générale/abstraite: si tu devais dire de quoi est composé un projet logiciel, tu dirais que c'est quoi ? Le contenu du git ? Il y a d'autres choses autour ?
A: Je ne sais pas trop quel périmètre tu mets à "projet".

Q: Ce qui m'intéresse c'est toi tu dis "voilà il y a un logiciel", c'est quoi le périmètre/contour du logiciel ?
A: J'aurais tendance à donner un contour super large, c'est à dire que j'écris du logiciel pour faciliter la vie des usagers, si c'est un logiciel qui pourrit la vie des usagers j'ai raté mon objectif. Donc au sens large, développer le bon outil qui facilite la vie des usagers ça va aller assez loin dans les discussions avec l'usager. Il va y avoir des documents, éventuellement des mails, des dessins, éventuellement de la documentation. Et le code de l'application. Il va y avoir une base de tests. On fait beaucoup de tests fonctionnels. Je fais très peu de tests unitaires : c'est bien quand on fait de algorithmique, mais dans la vraie vie on n'en fait jamais, dans la vraie vie on trie les petits pois sans réécrire la fonction de tri.

Q: Les discussions de conception font partie du logiciel selon toi ?
A: Oui, elles font partie du projet. Une fois que le logiciel est en prod, ça peut s'oublier. Une fois qu'on a 2 ans de prod derrière nous, les discussions initiales en général on les a oublié. Mais au moment de l'écriture c'est quand même des éléments importants.

Tout ça est aussi lié au contexte. Il y a des personnes en informatique qui sont une équipe de 20 pour un logiciel et nous on a tendance à une être équipe de 1 pour 20 logiciels. Donc on a un rapport qui n'est pas commun dans le monde du développement. On maintient 50 technologies en parallèle, ce qui peut amener de la frustration parfois. En terme de qualité de développement, on n'a pas forcément les même largesses pour faire tout ce qu'on veut autour du suivi. Typiquement un problème qu'on aurait envie de corriger mais pour lequel il n'y a pas les moyens. On est obligé d'arbitrer. Je ne suis pas naïf, donc j'imagine que les gens qui sont nombreux sur un unique produit, ils voient ça aussi. Mais on spécifiquement a du mal à faire les économies d'échelle. Quand tu es sur un produit, si il faut passer 50 heures à étudier une techno qui va te faciliter du temps derrière, tu peux le faire. Si tu es sur beaucoup de projets en parallèle, c'est moins gagné. Ou alors il faut arriver à mutualiser le savoir faire technique en question. C'est typiquement ce qu'on fait avec `cookiercutter`, mais on ne peut pas le faire sur tout. On aimerait bien mettre une intégration continue en place, on voit bien que ce n'est pas la même chose si tu mets une intégration continue pour un projet ou si tu le mets pour 50 projets. Ce n'est pas le même effort.

Q: Peux-tu me donner la liste des forges que tu utilises ou que tu as utilisé ?
A: La forge principale est celle de [Cliss XXI](https://forge.cliss21.org/) (Gitea). En parallèle j'utilise la [forge de l'April](https://forge.april.org) (Gitea). Il m'arrive d'utiliser GitHub et les forges d'autres projets, comme par exemple récemment la forge de borgmatic (Gitea). Il m'est arrivé d'utiliser la forge d'Enough qui est un GitLab. Récemment j'ai utilisé la forge de framasoft: framagit, qui est aussi un GitLab et le Trac de Django pour déposer un ticket. Il y a longtemps j'ai utilisé Fossil qui a été un vrai frein à la contribution: j'ai subi Fossil et j'en ai eu tellement marre que j'ai arrêté de contribuer au logiciel en question. J'ai également utilisé le SVN de Savannah.

Q: Est ce que tu as en tête un projet à propos duquel tu es amené à utiliser deux forges différentes ?
A:  Sur GvoT qui est hébergé sur la forge de Cliss XXI, j'ai eu un problème de validation W3C. En creusant je suis tombé sur un problème de dépendance au niveau de django-tapeforms qui est hébergé sur GitHub. J'ai ouvert un bug, je me suis mis d'accord avec le développeur sur le correctif à faire puis j'ai fait une pull request qui a été mergée.

Q: Comment as-tu fait dans le cas évoqué précédemment pour associer le fait que GvoT était impacté par le problème de l'autre projet hébergé sur GitHub ? Comment as-tu matérialisé ça ?
A: J'ai mis un hyperlien en commentaire du ticket de GvoT vers le ticket du projet django-tapeforms. J'ai un autre cas avec Bénévalibre qui est un projet Django. Un usager me remonte un problème lié aux noms de domaine internationalisés, qu'on n'avait jamais testé. En fait Django se comporte mal sur un certain point. J'ai ouvert un ticket sur la forge de Django, j'ai discuté avec les développeurs. Visiblement ça ne va pas bouger et rester buggé. Dans le ticket me concernant sur la forge de Cliss XXI j'ai fait une mention avec un hyperlien, le problème va être contourné de notre côté: l'upstream n'a pas l'air d'y voir un bug.

Q: Comment sauras-tu si des changements sont réalisés au niveau de ce problème des noms de domaine internationalisé ?
A: Et bien c'est assez embêtant, je le consulte périodiquement.

Q: Comment te souviens-tu de cette périodicité ?
A: Au moment où le bug est ouvert sur le projet impacté, le sujet est un peu chaud: je vais le voir de temps en temps. Une fois que j'aurai pris le temps de contourner le problème, je pense que je n'irai plus consulter ce bug.

Q: Par rapport au bug Django, tu ne reçois pas de notification ?
A: Oui, c'est cela. Le trac de Django n'est pas spécialement sympa à utiliser. Par défaut il n'y a pas de notification, je ne sais si les notifications sont supportées.

Q: Dans le cas d'une autre forge que celle de Cliss XXI, as-tu essayé de rentrer en contact avec une personne sans utiliser la forge (par exemple en envoyant en mail) ? Est ce que tu t'es déjà demandé comment contacter une personne autrement que par la forge ?
A: Oui, cela m'est déjà arrivé de me demander ça. Cela n'a pas toujours été concluant, cela n'a pas toujours marché. il y a des projets qui ont des mailing lists d'utilisateurs qui sont actives, ce moyen là est pas mal. Sur les projets un peu mono-personnel et qui vont être sur GitHub, en général la seule manière de contacter le développeur c'est de faire une issue.

Q: Est ce que cela t'es arrivé récemment de devoir contacter quelqu'un et de ne pas arriver à le faire facilement ?
A: Non. Avant je râlais parce que je n'avais pas de compte GitHub, maintenant que j'ai un compte GitHub je râle moins: je l'utilise.

Q: Pourquoi n'avais-tu pas de compte GitHub auparavant ? Qu'est ce qui t'a fait changer ?
A: Ça date d'avant le rachat de GitHub par Microsoft. Avant je voyais ça comme un truc de plus à gérer. Le rapport bénéfice/risque a basculé au moment où j'ai senti que j'en avais plus besoin.

Q: As tu déjà déplacé un projet d'une forge à une autre ? Si oui, peux-tu me donner un exemple ?

A: Oui. Un exemple récent: un projet qui était hébergé sur un dépôt Git (Gitolite). Il y a aussi un projet que j'ai migré de Redmine à Gitea il y a un an. J'ai essentiellement migré le dépôt Git. C'était un projet qui était inactif, les issues, page wiki et compte utilisateurs n'ont pas été migrés. Il n'y a pas eu de période de recouvrement: les deux forges n'ont pas été utilisées simultanément. Il n'y avait pas liste de diffusion associée à ce projet.

J'ai également un projet hébergé sur Savannah. Régulièrement quelqu'un remet une pièce "on devrait aller sur GitHub".
Le projet n'est pas migré parce que:
1. Malgré ses défauts, SVN est facile d'accès aux personnes qui ne sont pas développeurs. Et le projet concerné mobilise des contributeurs qui ne sont pas des core développeurs. Sur les projets pour lequel le développement est une caractéristique secondaire, SVN est plus facile à prendre en main que Git. Les forges modernes sont 100% Git, cela crée un frein. Mais bon, étant donné que cela va être de plus en plus difficile de trouver des gens qui savent utiliser SVN, l'argumentaire va s'estomper.
2. Concernant l'aspect politique, c'est un projet GNU qui n'a pas vocation à nourrir le léviathan Microsoft. Migrer à GitHub participerait à la concentration des forges et à rendre Microsoft un peu plus encore indispensable au mouvement du Libre.

Pour revenir sur la question de la définition des projet, ça me fait penser qu'on a tendance à mettre la documentation dans le code. Les éléments qui composent un peu l'aventure de l'écriture d'un logiciel ne sont pas tous traités comme un citoyen de premier niveau dans les forges libres, a fortiori les forges git.

Q: As-tu déjà utilisé les fonctions d'import/export des forges ?
A: Non

Q: Est ce que tu maintiens un miroir d'un projet sur une autre forge ?
A: Non

Q: Aujourd'hui, est ce qu'il y a des forges que tu ne choisis de ne pas utiliser ?
A: Plus maintenant mais ça a été le cas dans le passé. Ça m'est arrivé dans le passé de ne pas franchir le cap de la contribution parce qu'il fallait créer un compte et qu'il n'était pas possible de contribuer en anonyme.

Q: Qu'est ce qui t'a fait changer ?
A: Dans le passé, j'avais plus de détachement, je faisais des contributions sur des projets qui m'impactaient moi et des trucs qui étaient plus loin de moi. J'étais prêt à discuter autour d'un bug mais fallait pas trop que ce soit chiant. Par contre aujourd'hui je me retrouve dans un contexte professionnel donc j'ai beaucoup plus d'intérêt à travailler en collaboration avec l'upstream, la barrière à l'entrée est moins forte en comparaison de l'enjeu.

Q: Quelle est le logiciel de forge que préfères-tu utiliser ? Quel est le logiciel de forge que tu préfères en dehors de ceux que tu utilises tous les jours ?
A: J'utilise essentiellement Gitea aujourd'hui, je trouve que GitLab est un outil plus abouti. J'aime bien le côté simple de Gitea, j'aime bien le côté complexe de GitLab.
En 2009 on pouvait qualifier Redmine de forge, aujourd'hui j'ai du mal.

Q: Est ce qu'il t'est arrivé par le passé de participer au développement d'un logiciel sans pour autant utiliser la forge sur laquelle il est hébergé ?
A: Oui. Cela m'est arrivé dans le passé par exemple avec Grisbi pour lequel j'ai envoyé des patchs par mail.

Q: Est ce que tu connais des gens qui sont dans cette situation aujourd'hui ?
A: Non

Q: Est ce que tu connais une ou plusieurs forges qui excluent des gens en fonction de l'endroit où ils habitent ?
A: GitHub, ça ne doit pas être les seuls.

Q: Est ce que tu utilises des bots ou des outils en ligne de commande pour interagir avec des forges ?
A: À l'April on a un bot adhoc qui va surveiller l'activité de Redmine et la rapporte sur IRC.

Q: Est ce que tu as contribué ou écrit un bot qui interagit avec une forge ?
A: Non

Q: Est ce que tu as connaissance d'un bot ou d'un outil qui serait multi-forge ?
A: Non

Q: Comment fais-tu pour suivre les forks de ton projet ?
A: En général je les suis directement dans Git, j'utilise le visualiseur tig: j'ajoute les forks dont j'ai connaissance en remote dans Git.

Q: Si tu trouves quelque chose d'intéressant sur un fork, comment le gères-tu ?
A: Vu la nature des projets que j'ai, cela ne m'arrive pas vraiment. En général quand les gens veulent faire des évolutions ils les proposent, je ne vais pas chercher les choses: ce sont les gens qui proposent leurs contributions.

Q: Qu'est ce qui te motive à rajouter dans tes remotes un fork ?
A: Par le passé la personne a proposé du code, cela permet de le récupérer, de le lire et de le tester. Ensuite le remote reste.

Q: Te rappelles-tu d'un cas ou tu aurais découvert un fork que tu aurais trouvé intéressant pour une raison donnée ?
A: Non. Il est probable que cela m'arriverait si je relisais le code d'Enough par exemple.

Q: Quand tu utilises une forge qui n'est pas celle de Cliss 21, à qui dois-tu faire confiance pour garantir l'intégrité du logiciel qui s'y trouve et qui est utilisé par d'autres ?
A: En général je ne sais pas trop. Bien sûr c'est l'hébergeur. Il y a un nombre modeste de projets que je récupère directement depuis les forges. Il y a un nombre moins modeste de projets que je récupère via pip et cela m'[inquiète](https://metrodore.fr/i-have-been-powned.html) [désormais](https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090). Il n'y a pas de relation de confiance comme on peut avoir avec une communauté Debian. On a même des situations comme celle où Sourceforge a interféré en livrant des binaires Windows modifiés pour introduire des malwares. Je fuis activement Sourceforge - à la fois pour une expérience politique et à la fois pour une expérience utilisateur désastreuse - mais il y a encore des projets qui y sont hébergés.

Q: Comment tu t'assures que les commits que tu pushes ne sont pas réécrits.
A: Je ne m'en assure pas, aujourd'hui je ne signe pas mes commits.

Q: As-tu entendu parlé de la possibilité d'utiliser une attaque de collision SHA1 pour réécrire l'historique d'un dépôt Git de façon transparente ?
A: Non. Je connais les faiblesses de SHA1 mais j'ignore qu'une démo de réécriture d'historique Git ait été révélée.

Q: Dans un contexte d'utilisation de plusieurs forges, si tu avais une baquette magique, qu'est ce que tu voudrais qui existe et qui te faciliterait la vie dans la façon dont tu utilises plusieurs forges ?
A: Dans l'hypothèse d'une forge Git: faire une pull-request interforge, c'est à dire prendre l'URL d'un projet, demander à la forge de le forker et que je puisse travailler dessus et ouvrir une pull-request/merge-request sur la forge parente. Le tout, idéalement, sans avoir de processus lourd de création ou preuve d'identité.

Q: Dans un contexte d'utilisation de plusieurs forges, est ce qu'il y a un truc qui marche vraiment bien ?
A: L'authentification via GitHub (et c'est triste).