Entretien avec Dimitri Fontaine, développeur PostgreSQL

Rédigé par Carl Chenet - -

Jdh : Bonjour Dimitri et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Dimitri : Bonjour Carl, merci de me proposer de réaliser ensemble cette interview, cela flatte mon égo :) Je travaille aujourd'hui en tant qu'Architecte Logiciel et Expert PostgreSQL, projet auquel j'ai contribué et suis reconnu en tant que PostgreSQL Major Contributor. J'ai contribué en particulier aux notions d'Extension et d'Event Trigger pour PostgreSQL.

Mon outil de travail principal est Emacs, dont la gestion des modules complémentaires laissait à désirer il y a quelques années. J'avais alors retroussé les manches et développé el-get, encore beaucoup utilisé aujourd'hui. Ce projet bénéficie maintenant d'une équipe de mainteneurs actifs, ce dont je suis très content !

Après avoir découvert le lisp avec Emacs Lisp, je me suis naturellement intéressé à Common Lisp… et c'est aujourd'hui mon langage de programmation préféré, ou secondaire dirait James Hague. Et comme le projet pgloader avait besoin d'être revu complètement, je l'ai réécrit en Common Lisp. C'est le projet libre auquel j'accorde aujourd'hui toute mon attention, et j'ai eu beaucoup de retours d'utilisateurs ayant migrés des bases complètes vers PostgreSQL en une seule commande.

Jdh : Commençons par ta participation au projet PostgreSQL. Peux-tu nous dire comment tu en es venu à l'utiliser et nous décrire rapidement ton parcours de, j'imagine, simple contributeur à PostgreSQL Major Contributor ?

Dimitri :Dans le cadre de mes études (IUT Génie Informatique puis École d'Ingénieur, l'ISTY, dépendante de l'université de Versailles) nous avions des cours de base de données relationnelle. À l'école rien n'était installé pour les travaux pratiques et j'ai donc porté la demande auprès de notre administrateur système, et nous avons fini par installer PostgreSQL.

J'ai alors découvert un projet facile à utiliser et dont la documentation complète permet de comprendre le fonctionnement du produit dans son intégralité. Et surtout, chaque commande présentée dans la doc fonctionne exactement comme elle est présentée. C'est reposant ;)

Plus tard, j'ai créé avec des copains une petite entreprise de services en logiciel libre, très orientée Linux et dont le nom intégrait une référence relativement subtile au site d'information des libristes français le plus visité de l'époque… saurez-vous retrouver le slogan qui a inspiré le nom « Da Linux Boite », ainsi que le vrai nom de l'entreprise (toujours en activité) ?

Rapidement, le marché principal sur lequel nous intervenions avec succès étant PostgreSQL, nous avons adapté notre organisation et notre offre commerciale afin de nous concentrer sur cette technologie, ses usages et ses difficultés.

Cette expérience m'a permis de travailler ensuite en tant que DBA (DataBase Architecte plutôt qu'Administrateur, PostgreSQL permettant d'aller beaucoup plus loin que les bases de données relationnelles telles qu'elles sont habituellement envisagées). Dans ce rôle de DBA avancé, j'ai eu l'occasion de mettre au point une extension dédiée au métier d'opérateur téléphonique, comprenant un type de données avec support d'indexation spécifique.

Ce développement m'a permis de découvrir les API et outillages internes de PostgreSQL, et de commencer à lire le code de mon SGBDR préféré. Ce projet a également été l'occasion de comprendre l'étendue du support apporté sur le canal IRC #postgresql sur freenode, où j'ai été accompagné et conseillé dans mes découvertes.

Du coup en parallèle au développement de l'extension prefix et de mon apprentissage approfondit des aspects internes de PostgreSQL (le produit, le projet et la communauté), je participe beaucoup aux listes officielles où je propose mon avis sur tous les sujets qui me plaisent, c'est à dire presque tout ce qui s'y passe… en m'efforçant de toujours rester constructif et faire avancer la situation.

La suite est une histoire habituelle de l'Open Source : la communauté est accueillante, la documentation pourrait être améliorée et c'est le premier patch. Ma première contribution à PostgreSQL est facilement visible encore aujourd'hui, il suffit de comparer la page dans la version 8.3 avec celle de la version 8.4.

Le plaisir d'avoir pu contribuer à un projet aussi reconnu que PostgreSQL m'a donné la motivation nécessaire à passer à la vitesse supérieure. S'il était déjà facile de réaliser une extension incluant un type de données et son indexation spécifique, la restauration des sauvegardes de bases utilisant les extensions était… à revoir. Je m'y attelais et contribuais les commandes CREATE|DROP|ALTER EXTENSION ; cela constitue ma première contribution au code (en C) de PostgreSQL.

Pour le bénéfice des lecteurs de cette interview, je me permettrais de conseiller un projet moins ambitieux dans le cadre d'une première contribution : ce projet là a duré plus de 2 ans et demi et n'a pu aboutir que grâce à ma participation aux Developer Meeting à Ottawa. Sans la rencontre en personne avec les développeurs, les chances de succès d'une telle entreprise auraient été nulles. L'appui sérieux de mon employeur de l'époque (Hi-Media, merci Franck !) a été fondamental.

La meilleure façon de commencer à contribuer à un logiciel Open Source reste la correction de bugs. La mise au point du premier correctif peut prendre plusieurs semaines, ou plusieurs mois, car il est nécessaire de se familiariser avec le code, les APIs, les usages, l'environnement de tests, la documentation, les outils de communication de la communauté du projet (des mailing-listes pour PostgreSQL, une Pull Request consiste à envoyer un patch obtenu avec la commande diff en pièce jointe à son mail dans lequel on décrit le travail réalisé). La mise au point du correctif suivant est en général beaucoup plus rapide, compter quelques heures ou quelques jours. Et si l'on est régulier dans la correction de bugs, on est rapidement intégré et apprécié dans le projet !

Et pour terminer de répondre à la question, le projet PostgreSQL est assez bien organisé, jusque dans la reconnaissance de ses contributeurs. Après 2 ans et demi et 31 versions du patch pour la gestion intégrée des extensions, j'ai donc été reconnu PostgreSQL Major Contributor, ce qui est clairement visible sur la page de référence de la communauté.

Jdh : Peux-tu nous en dire un peu plus sur pgloader, un projet qui approche les 700 étoiles sur ton compte GitHub et qui semble avoir une histoire mouvementée (TCL, puis Python puis Common Lisp si je me réfère au README du projet) et ton rôle dans ce projet ?

Dimitri : En 2005, si je me souviens bien, nous avions un projet de migration d'INFORMIX à PostgreSQL. Il était assez facile d'extraire les données de la base source sous un format relativement proche du CSV, mais très facétieux, et l'outil de référence de chargement de CSV facétieux à l'époque était déjà pgloader, en TCL et peu maintenu.

Après avoir tenté de modifier le code TCL pour de la gestion d'encoding et de chaînes binaires, j'ai préféré reprendre le code (très simple à l'époque, il ne gérait que la reprise sur erreur autour de COPY) pour lui ajouter les options avancées de lecture du format improbable que nous avions à charger, et à l'époque Python a été mon choix.

Le format de configuration de pgloader était alors un .INI dont nous avons assez rapidement atteint les limites. J'ai voulu alors implémenter une configuration avancée avec une grammaire propre, et je me suis heurté de plein fouet à l'incompatibilité de certaines libs python entre les versions 2 et 3 du langage.

Dans la même période, pgloader montrait des faiblesses en terme de performances, et personnellement j'avais découvert Emacs Lisp et réalisé un projet conséquent dans le langage, je voulais investiguer Common Lisp.

Après avoir joué un peu avec Common Lisp sur d'autres projets annexes, convaincu par son mode de développement interactif et la modernité des outils proposés par le langage, j'ai développé un prototype du nouveau pgloader lors d'une migration de MySQL vers PostgreSQL chez un client.

Le pgloader nouveau était alors un projet en cours, et aujourd'hui nous avons de nombreux utilisateurs qui migrent leurs données en une ligne de commande, ou bien importent chaque nuit des quantités de données importantes avec reprise sur erreur automatique.

L'impact principal du choix de Common Lisp réside dans la capacité à développer une nouvelle fonctionnalité, entreprendre un refactoring avancé du code ou bien fixer un bug dans un temps record. Étant donné que pgloader est un projet que je fais vivre sur mon temps libre, pouvoir faire en 2h un soir ce qui me prenait autrefois toutes mes soirées de la semaine est un avantage indéniable !

Au niveau de mon rôle dans le projet, aujourd'hui je suis seul à m'occuper de tout. J'aimerais réussir à construire une équipe de développement et de maintenance comme j'ai pu le faire avec el-get par exemple, et je pense que pgloader est maintenant assez mûr pour cela.

Jdh : Tu me tends une perche que je vais m'empresser de saisir. Tu es également le créateur du projet el-get, qui est, sauf erreur de ma part, un outil pour installer simplement des extensions ou des scripts externes pour Emacs. Peux-tu m'en dire un peu plus sur ton utilisation d'Emacs et comment tu en es venu à écrire cet outil ?

Dimitri : À l'époque où j'ai démarré el-get, mon utilisation d'Emacs ressemblait déjà beaucoup à celle d'aujourd'hui : écriture de code et de documentation, shells interactifs avec M-x shell, emails avec gnus, IRC avec rcirc, le tout avec escreen afin de ne pas perdre la tête.

Ma configuration est en fait une personnalisation avancée de l'outil, avec par exemple des raccourcis me permettant d'adapter le visuel (taille et emplacement des fenêtres, disposition automatique pour IRC en fonction de la taille de l'écran, et plus de modifications aux fonctions de base proposées par Emacs que je ne puis m'en souvenir).

On en est au point où j'ai plus de 5000 lignes de code personnel chargé à chaque lancement d'Emacs (environ une fois par mois), et où je maintiens une configuration minimale (de 150 lignes) : je ne sais plus utiliser Emacs sans quelques changements clés.

Lorsque je commence el-get, il n'existe pas encore de solution de packaging intégrée à Emacs et il faut trouver et maintenir des scripts Emacs Lisp plus ou moins maintenus, souvent sur Emacs Wiki, et les gérer et les distribuer soi-même. L'idée de fond était de pouvoir maintenir une configuration déclarative d'une part, et un jeu de « recettes » faciles à échanger d'autre part.

Le projet a bien marché, si on utilise à nouveau la mesure des stars de GitHub on est à plus de 1200 aujourd'hui, et surtout, le projet est maintenu par une équipe et je ne fais plus grand chose : c'est le plus beau succès de l'Open Source, devenir simple utilisateur de son propre projet.

Jdh : Pour revenir à PostgreSQL et sauf erreur de ma part, tu es le président de la société Second Quadrant France, qui fournit du service autour de PostgreSQL. En tant qu'entrepreneur du Libre, je suis intéressé par ce modèle. Peux-tu nous détailler un peu l'histoire de cette société et quelles sont ses activités aujourd'hui ?

Dimitri : Apporter les valeurs du logiciel libre aux entreprises est quelque chose d'important pour moi, et créer une société de service et d'expertise PostgreSQL s'inscrit pour moi parfaitement dans cette ligne.

2ndQuadrant a été créée il y a environ 15 ans et emploie aujourd'hui un nombre très importants de contributeurs PostgreSQL. L'idée étant que le seul moyen d'apporter de l'expertise sur un logiciel libre est de participer à son développement. Il s'agit bien sûr de proposer des améliorations (correctifs, nouvelles fonctionnalités, etc) mais aussi de s'engager dans le processus de développement (revue de code, participation aux discussions de conception et de choix des fonctionnalités sur lesquelles travailler, etc.).

J'ai eu la chance de pouvoir établir 2ndQuadrant en France en créant l'entreprise avec mon associé Cédric Villemain. Aujourd'hui cependant ma situation personnelle m'a aiguillé vers un nouveau rôle, et je laisse 2ndQuadrant aux soins compétents et éclairés de Cédric.

Les activités de 2ndQuadrant sont toutes centrées autour de la notion de service et d'expertise PostgreSQL et couvrent toutes les étapes de l'utilisation de la solution de traitement de données préférée de tous ses utilisateurs : formation, conception, optimisation, gestion de la production (outils, méthodes, processus, interventions en cas d'incidents), support 24×7, accompagnement, développement à façon, etc.

Vous pouvez retrouver l'ensemble de nos services sur le site de 2ndquadrant.

Pour illustrer le modèle de 2ndQuadrant, prenons l'exemple du support : il est réalisé par des contributeurs PostgreSQL et nous nous engageons à corriger nous-mêmes les avaries logicielles rencontrées par nos clients. Nous nous y engageons car nous disposons du savoir faire requis, simplement parce que les équipes de 2ndQuadrant sont distribuées dans plus de 15 pays couvrant l'ensemble des fuseaux horaires et sont constituées de contributeurs PostgreSQL.

Cela permet en outre aux contributeurs PostgreSQL de 2ndQuadrant de mieux comprendre les besoins des utilisateurs et de les adresser de manière précise et efficace en développant les fonctionnalités les plus utiles dans chaque nouvelle version de PostgreSQL. On peut ainsi parler de cercle vertueux.

C'est le modèle le plus classique de service en logiciel libre, et pour approfondir le sujet je recommande la lecture des livrets bleus édités par le groupe Systematic. Les livrets sont disponibles en ligne aux liens suivants (format PDF disponible gratuitement) ici et .

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Classé dans : Entretien - Mots clés : aucun

Entretien avec Raphaël Hertzog, développeur Debian

Rédigé par Cascador - -

Jdh : Bonjour Raphaël et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Raphaël : Je m'appelle Raphaël Hertzog, j'ai 36 ans, je suis marié et j'ai deux garçons (de 2 et 5 ans). Je vis près de Saint-Étienne (à Sorbiers) et j'y travaille aussi puisque je gère ma société (Freexian SARL) depuis chez moi et que l'ensemble de mes missions s'effectuent en télé-travail. Comme je suis très sédentaire, je pratique le badminton à un bon niveau pour entretenir ma forme physique.

Je suis développeur Debian depuis 1997 (ça fait 18 ans, soit la moitié de ma vie !) et j'ai déjà touché à plein de choses au sein du projet... des paquets importants (comme debian-cd, developers-reference, dpkg, python-django), l'administration de certains services (alioth.debian.org), la présidence de Debian France, l'organisation de Debian LTS, …

Mais ce qui m'attire le plus c'est de travailler sur l'infrastructure qui permet à tous les contributeurs d'être plus efficace et de faire un travail de meilleure qualité. Historiquement c'est l'équipe d'Assurance Qualité qui a cristallisé ce genre de projets et c'est au sein de cette équipe que j'ai créé le Package Tracking System et que je maintiens maintenant son successeur, le Debian Package Tracker (une réécriture en Django initiée lors d'un Google Summer of Code).

Accessoirement, je suis également l'auteur du Cahier de l'Admin Debian qui a donné naissance au Debian Administrator's Handbook (Roland Mas est devenu co-auteur avec moi au fil des éditions).

Jdh : C'est en effet l'infrastructure Debian qui assure à tous les contributeurs de ce projet de bonnes bases pour contribuer. Peux-tu nous donner quelques informations sur les efforts entrepris récemment dans ce domaine, les nouveautés déjà disponibles et peut-être celles à venir ?

Raphaël : Ben justement je n'ai pas l'impression qu'on ait fait beaucoup de progrès récemment sur ces thématiques. On peut tout de même citer sources.debian.net qui permet de naviguer facilement dans les sources des paquets Debian, de fournir un lien vers une ligne précise de code, ou vers un patch que Debian applique. Associée à l'extension Firefox/Chromium de Raphaël Geissert, on peut facilement créer un patch sur n'importe quel logiciel empaqueté dans Debian.

Il y a aussi le Debian Maintainer Dashboard qui a été mis en place en s'appuyant sur UDD (Ultimate Debian Database). Mais il fait doublon avec le DDPO (Debian Developer's Package Overview).

Enfin, je citerai volontiers dgit, car l'idée d'avoir une infrastructure centralisée permettant de gérer des paquets Debian simplement avec git est plutôt plaisante. Mais j'ai peur que le projet ne soit voué à l'échec car le projet souffre de limitations importantes : aucun historique n'est disponible sur les paquets, même lorsque le mainteneur utilise déjà git avec le paquet.

En ce qui concerne le futur et n'étant pas devin, je peux simplement donner quelques projets que j'aimerai voir aboutir et sur lesquels je vais sûrement essayer de travailler :

  • Modifier le Package Tracker pour gérer qui est responsable de quoi sur chaque paquet. Il s'agit de remplacer le concept un peu binaire qui veut que soit le paquet a un mainteneur et dans ce cas on suppose qu'il gère tout et que tout va bien, soit le paquet n'a pas de mainteneur et dans ce cas il est abandonné et rien ne va plus.
  • Dans la pratique on a souvent des mainteneurs qui ont besoin du paquet en dépendance d'un paquet qu'ils utilisent et qui vont corriger juste les bogues critiques mais qui laisseraient volontiers le paquet à un mainteneur plus intéressé. Ou alors on a des mainteneurs enregistrés mais qui en fait ne sont plus actifs et le paquet est négligé...

    Et puis on a de plus en plus d'utilisateurs externes qui dépendent de certains paquets dans Debian qui doivent pouvoir les surveiller pour s'assurer qu'ils ne seront pas supprimés dans la prochaine version (ce qui arrive de plus en plus souvent avec la politique de suppression automatique lorsqu'un bogue critique n'est pas corrigé sous 30 jours).

  • Étendre le Package Tracker pour qu'il intègre toutes les fonctionnalités de suivi / coordination qui existent actuellement dans divers services séparés : suivi par contributeur (cf DDPO/DMD déjà cité), suivi par équipe (cf Package Entropy Tracker), coordination de transitions (cf transition trackers de la Release Team)
  • Rationaliser le flux d'informations à destination des mainteneurs. J'avais déjà formalisé les objectifs à atteindre dans le DEP-2 rédigé il y a plus de 4 ans...

Jdh : Tu es au centre de l'initiative Debian LTS, qui fournit un support de longue durée aux différentes versions stables de Debian. Peux-tu nous en dire un peu plus, sur par exemple l'origine du projet, les moyens mis en œuvre, les avancées du projet et ses objectifs ?

Raphaël : Moi j'ai suivi cela de très près et lorsque le projet a été lancé et que quelques propositions d'aides financières ont été émises j'ai immédiatement proposé aux autres contributeurs intéressés par être payés pour travailler sur Squeeze LTS de s'unir derrière une offre unique que l'on pourrait mettre en avant.

C'est ainsi qu'est née l'offre Debian LTS de Freexian. Et à ce jour l'essentiel des contributions à Debian LTS proviennent de contributeurs financés par les sponsors gérés par Freexian. J'ai fait quelques statistiques à ce sujet que j'ai présenté lors de la DebConf (diapos, vidéo).

Personnellement j'estime que c'est un succès, mais un succès modeste tout de même, il nous a fallu plus d'un an pour arriver à financer l'équivalent d'un mi-temps. Quand on sait les moyens financiers des grosses entreprises, on se dit qu'on peut faire bien mieux. Et j'espère effectivement qu'on va réussir à convaincre d'autres entreprises pour pérenniser le projet et se donner des marges de manœuvre que l'on n'a pas encore.

D'ici quelques mois nous allons passer à Debian 7 Wheezy LTS parce que Debian 6 arrivera au terme des 5 ans de support et nous allons essayer d'avoir moins de restrictions en terme de paquets supportés (notamment sur les technologies de virtualisation)... mais il faudra des moyens supplémentaires si l'on ne veut pas que d'autres paquets en pâtissent à terme.

L'objectif de Debian LTS est simple : supporter l'ensemble des paquets Debian pendant 5 ans (sur les architectures où il y a des utilisateurs qui cherchent une version LTS). Mais les moyens d'y arriver sont multiples, d'un côté il faut travailler au jour le jour en corrigeant les CVE sur la version courante, et de l'autre il serait bon de faire un travail en amont pour s'assurer que les logiciels intégrés à Debian 9 Stretch puissent être maintenus pendant 5 ans supplémentaires ! Mon objectif est bien d'arriver à une situation où nous avons assez de ressources pour pouvoir avoir un impact sur les versions en développement et pas seulement sur la version LTS actuelle.

Au delà, j'aimerai que LTS soit une porte d'entrée pour que les entreprises prennent conscience de l'importance de leur implication et qu'ensuite elles contribuent non seulement à LTS mais aussi à d'autres projets Debian qui leur seront bénéfiques à plus long terme.

Jdh : Passons maintenant à un sujet qui passionne les utilisateurs du Logiciel Libre : les rapports Debian-Ubuntu. Toi qui es au cœur du projet Debian depuis des années, peux-tu nous retracer rapidement l'évolution de ces rapports et l'état actuel des interactions entre les deux projets ?

Raphaël : Je ne crois pas que cela soit encore un sujet si passionnant. Il y a eu des tensions au début lorsque Canonical avait embauché un grand nombre de développeurs Debian et qu'ils n'avaient pas les moyens de contribuer en retour à Debian. De nos jours, la communauté Ubuntu est plus large que juste les employés Canonical et les relations sont bien meilleures. De nombreux contributeurs Debian sont aussi des (anciens) contributeurs Ubuntu.

Le plus gros regret que j'ai c'est que Canonical n'ait jamais fait l'effort d'essayer d'intégrer ses développements les plus importants dans Debian, comme Unity par exemple.

Jdh : Tu es connu du grand public pour ton livre "The Debian Administrator’s Handbook" en anglais ou "Cahier de l'admin Debian" en français qu'on aime beaucoup. On trouve également géniales les initiatives que tu as lancées pour libérer les différentes versions. Peux-tu nous parler dans un premier temps de ces initiatives de libération, puis dans un second temps du processus de production du livre en lui-même tel qu'il est aujourd'hui (auto-édition, revue "communautaire", etc) ?

Raphaël : Le livre français avait été écrit pour le compte des éditions Eyrolles et c'est donc eux qui contrôlaient les droits sur le livre. N'ayant jamais réussi à en faire publier une traduction anglaise, Eyrolles a accepté de nous rendre (à moi et Roland) les droits sur une éventuelle traduction anglaise. La première campagne de financement visait simplement à nous donner les moyens de faire ce travail de traduction, avec un palier bonus où la traduction était en plus publiée sous licence libre.

Une fois cet objectif atteint, il restait le livre français sous licence propriétaire alors que le livre anglais était libre. Il fallait corriger cela et cela nécessitait de renégocier avec Eyrolles et de les convaincre que libérer le livre français était la bonne solution. On a profité d'une nouvelle édition à venir pour imaginer un plan gagnant-gagnant : une nouvelle campagne de libération permettait à la fois à Eyrolles d'écouler son stock de livre de l'édition précédente, de financer les frais d'édition de la prochaine édition et de financer une partie du travail des auteurs. Ainsi même si le livre ne se vendait pas (parce qu'il était libre), Eyrolles ne perdrait pas (trop) d'argent.

Au final, le livre français continue de se vendre, même si les chiffres sont plutôt faibles (moins d'un millier d'exemplaires par an).

D'un point de vue plus technique, le livre est rédigé en DocBook XML, il est maintenu dans un dépôt Git comme tout projet libre qui se respecte, les traductions sont gérées avec Publican qui génère des fichiers .po (et les traducteurs mal à l'aise avec les fichiers .po peuvent utiliser Weblate). Le PDF du livre papier est généré avec dblatex et une feuille de style LaTeX personnalisée. Il est imprimé à la demande par Lulu.com pour la version anglaise tandis que la version française est toujours éditée par Eyrolles.

Il se trouve justement que je passe pas mal de temps sur mon livre ces derniers temps car nous sommes en train de finaliser la version Jessie (Debian 8) du livre. J'invite ceux qui veulent être prévenus de la sortie de mon livre à s'abonner à ma newsletter (soit en anglais, soit en français). Et vous pouvez aussi déjà en profiter en ligne bien que la traduction ne soit pas terminée... et nous signaler les éventuelles coquilles avant sa publication !

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Fil Rss des articles de cette catégorie