Hackathon au Wikimania 2016

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.

wikimania_esino_lario-2-b8f21

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.

# exemple d’une session shell faisant usage de vagrant
vagrant roles list|grep mobile # recherche du module dédié à l’interface mobile
vagrant roles enable mobilefrontend  # configurer l’activation du greffon
vagrant provision # appliquer les modification de configuration
# hack, hack, hack…
# hmm, il semble y avoir des conflits avec le greffon translate, désactivons le pour le moment…
vagrant roles disable translate --provision # appliquer directement la modification de configuration
vagrant ssh # connexion ssh à la machine virtuel

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 :

Court message explicatif

Un message optionnel, plus long qui décrit de façon
 plus détaillé ce qui a été fait et les points notables.

Bug: T42

En respectant cette convention il suffit alors d’exécuter

git review

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

# hack hack git commit # youps, non car on ne souhaite pas créer plusieurs commit pour des correctifs suite à une revue

git rebase --interactive HEAD~~ # remodeler l’historique, ici on fusionne les deux derniers commits en remplacant 'pick' par 'f' (ou 'fix') sur la seconde ligne du fichier édité par cette commande

git reflog # permet de voir le journal des modifications, dont les remodelages d’historique

git review # En espérant que ce soit mieux 

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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.