Wikimania est « une conférence internationale rassemblant chaque année les contributeurs aux projets de la fondation Wikimedia », durant laquelle se tient également un hackathon dédié aux projets Wikimédia dont la célèbre encyclopédie libre Wikipédia. Ce billet fait une rétrospective sur l’édition 2016.
La session d’ouverture du hackathon commence par une séance de présentation des organisateurs de l’événement qui ont œuvré pour rendre possible la réunion d’un millier de contributeurs dans ce cadre italien idyllique qu’est Esino Lario, suivi par une séance de présentation des personnes animant des sessions ou des ateliers ainsi que des porteurs de projets. Les sujets fusent, et chacun peu repérer qui consulter pour les thèmes qui retiennent le plus son attention : langage engineering, ORES le projet d’évaluation des articles par intelligence artificielle, intégration de Wikidata le projet de base de données structurée, gestion des tableaux dans les exports PDF des articles…
Découverte de l’infrastructure technique
Le programme est vaste et dense, impossible de tout voir et il faut nécessairement faire des choix, bien que de nombreuses sessions soient filmées et disponibles sur Commons et ailleurs sur le Web. La vue d’ensemble de l’infrastructure technique de Wikimédia est une excellente session en guise d’introduction à l’ensemble de l’écosystème technique utilisés dans les divers projets. Elle permet de repérer globalement comment s’agencent les différentes composantes techniques, et sur quelles technologies elles reposent. Sur ce plan également, il s’agit d’un environnement très hétérogène : si Mediawiki, le moteur de wiki, repose principalement sur une plateforme LAMP, l’écosystème qui gravite autours utilise entre autres du C++, du Java, du Lua, du Perl et du Python ! Les applications correspondantes ne sont pas moins variées : applications natives pour mobiles, automates d’édition (bots), outils d’aide à la revue des modifications, outils de consultation hors-ligne…
Vers une première contribution technique
À propos de Mediawiki
Le moteur de wiki Mediawiki étant historiquement la pièce centrale de l’environnement Wikimédia, il est intéressant de s’attarder plus particulièrement sur cette brique technologique. Cela étant, il n’est absolument pas nécessaire d’installer ce logiciel pour démarrer un projet technique qui communique avec lui. Il existe bien entendu une API qui permet de piloter des instances déjà en place depuis n’importe quel langage. Et même sans cela il est possible de coder directement au sein des wikis : depuis ses débuts le projet permet de créer des modèles dans un espace de nom dédié qu’il est possible de transclure dans n’importe quel article. Au fil du temps la syntaxe de ce langage de templating c’est enrichi avec notamment des structures de contrôle. Malheureusement le résultat de cet accroissement organique non-planifié produisait la plupart du temps un code abscons à la maintenabilité relevant souvent de l’aventure épique en plus de poser de gros soucis de performance. C’est pourquoi le greffon Scribunto fut introduit pour permettre l’utilisation de langages utilisant des interpréteurs externe au moteur du wiki. Au sein de Wikimédia, c’est le langage Lua qui est utilisé pour créer des scripts dans l’espace de nom dédié, celui-ci ayant été retenu pour sa facilité à se greffer sur un environnement existant, en plus de sa maturité éprouvé dans les systèmes à forte contrainte en performance sur des calculs temps réel, comme dans les jeux vidéos où il est également très employé.
Mise en place d’un environnement de développement
L’un des atelier de ce hackathon proposait justement de s’initier au développement Mediawiki à l’aide de Vagrant. Il est bien sûr possible d’installer un environnement manuellement mais puisque les outils de virtualisation sont disponibles, autant en profiter ! À noter cependant que Vagrant s’appuie sur de la virtualisation complète, ce qui – entre autres facteurs – rend la mise en place de cet environnement beaucoup plus longue : prévoir quelques heures pour la première exécution de vagrant provizion. Mais passer ce cap, l’environnement virtualisé permet tout de même de facilement lister, activer et désactiver tout un ensemble de greffons (nommés role dans ce contexte). Cela permet notamment de réduire rapidement l’installation au plus petit ensemble de greffons nécessaire pour le développement, en évitant la lourdeur d’une instance les cumulant au grès des développements, et d’isoler les problèmes d’intégration à une phase de développement dédiée.
Processus de revue de code
Au niveau de la revue de code, le projet utilise gerrit, couplé a Phabricator pour la gestion de suivi des incidents. Les instances de ces deux derniers sont configurées pour analyser les messages de journalisation de git, ces messages devant donc suivre un formatage bien défini. Par exemple si le commit correspond au ticket 42 :
En respectant cette convention il suffit alors d’exécuter
Pour que :
- le commit soit intégré à l’instance gerrit ;
- l’entrée gerrit indique le ticket Phabricator ;
- le ticket Phabricator pointe vers gerrit.
Une fois qu’une autre personne aura fait la revue du commit et trouvé moult problèmes à corriger (tout au moins en général), il suffira de rentrer dans un cycle de modification/proposition
That's all folks!
Voilà pour les très grandes lignes, la suite dans un prochain épisode ! En espérant que des explications succinctes et beaucoup de pointeurs pour en apprendre davantage conviendra au lectorat, tous les retours et toutes les questions sont les bienvenues.