Geospatial – Actualités

14ème Rencontre Développeurs de QGIS aux Îles Canaries

26 novembre 2015

Camptocamp était présent au 14ème Hackfest de QGIS qui s’est déroulé à l’Université de Las Palmas, aux Îles Canaries du 5 au 8 Novembre 2015.

QGIS_photo-groupe

Deux sujets de discussion ont particulièrement retenu notre attention : la future version 3 de QGIS et notamment ses extensions et la gestion du projet et des contributions. Ces deux sujets constituent aujourd’hui deux problématiques importantes que le projet doit résoudre. Voici une courte explication ainsi que les pistes de résolutions évoquées.

Ces deux problématiques (c-à-d « comment gérer les versions majeures d’un projet » et  « comment gérer les nombreuses contributions ») sont classiques dans un projet Open Source d’envergure comme celui de QGIS. En effet, d’une part, celui-ci reçoit une grande quantité de contributions en provenance d’une large diversité de développeurs et, d’autre part, nous devons prévoir l’évolution du projet pour les prochaines années.

Amélioration du processus de contribution

Depuis quelques temps, si vous suivez le projet QGIS, vous vous êtes probablement aperçu du nombre croissant de contributeurs. Par conséquent, le nombre de modifications qui sont apportées au code augmentent dans les mêmes proportions. Le projet a un système de release qui peut avoir un impact sur le délai de disponibilités des fonctionnalités développées pour la version suivante.

Tous les 3 mois, le code rentre dans une période de « freeze » de fonctionnalités durant 5 semaines pendant laquelle aucune nouvelle fonctionnalité ne peut être ajoutée. Cette période a pour objectif de corriger les problèmes issus de la période précédente, centrée sur l’ajout de fonctionnalités. La période de « freeze » permet également de traduire le logiciel. Vous l’avez donc compris, ces 5 semaines sont une période toute aussi active pour les développeurs. Elle est cependant critique car il faut fournir une version de qualité, la plus stable possible. Dans l’idéal, les développeurs terminent le développement des fonctionnalités avant cette période de « freeze ».

schema_QGIS

Cependant, une contribution n’est pas uniquement du code à écrire. C’est un processus bien plus complexe et plus long. Il y a un vrai travail préparatoire pour répondre à une demande initiale qui peut nécessiter d’ailleurs quelques échanges supplémentaires. Puis le projet est lancé avec une ou plusieurs phases de développement, de validation de la part du client et enfin l’intégration finale du code dans le projet QGIS. Le client s’attend généralement à voir sa fonctionnalité disponible rapidement mais en fonction de l’importance du développement, deux cas peuvent se produire :

  1. l’importance de la fonctionnalité nécessite l’écriture d’un document appelé QEP (QGIS Enhancement Proposal). Les développeurs vont anticiper sa rédaction en amont du développement, puis il sera voté et accepté par le PSC. Celui-ci n’est cependant pas obligatoire et peut être demandé en cours de développement.
  2. la plupart des projets d’envergure ont un processus de relecture de code afin que d’autres développeurs puissent relire la contribution et laisser un commentaire. Ce processus peut retarder l’intégration finale du code car il est basé sur du bénévolat. QGIS utilise ce genre de processus de relecture.

Revenons au processus de release dans sa globalité. La fréquence de 4 mois constitue un rythme soutenu mais elle permet à un financeur de voir sa fonctionnalité disponible rapidement dans une version officielle. Un premier problème apparaît : il est tout à fait possible de voir sa contribution retardée et donc d’avoir 4 mois de retard sur un projet. Ces retards sont essentiellement dus à un goulot d’étranglement au niveau de la relecture du code ou de la nécessité de rédiger une QEP et d’attendre un retour de la communauté.

Les discussions lors du Hackfest avaient donc pour objectif d’améliorer cette situation. Il en ressort les points suivants (attention, ce ne sont que des réflexions pour le moment) :

  • obliger les développeurs (core et contributeur) à passer par des Pull Requests (système permettant de proposer des modifications de code et qui permet de visualiser les modifications proposées) ;
  • laisser du temps aux relecteurs (les autres développeurs) pour rédiger des commentaires ;
  • permettre aux développeurs d’intégrer leur contribution après un certain délai ou après que des corrections aient été apportées suite aux commentaires des autres développeurs ;
  • demander aux contributeurs de financer le temps de relecture puisque celle-ci apporte une qualité supplémentaire dans les propositions de code.

Une QEP est, bien entendu, en cours de rédaction pour préciser tout cela.

Quelques informations supplémentaires :

Chez Camptocamp, nous nous organisons de cette manière sur nos projets internes d’envergure ou communautaires pour réaliser ces relectures de code. C’est le cas, par exemple, pour les projets OpenLayers ou GeoMapFish. Néanmoins, en fonction de la taille des projets communautaires ce n’est pas toujours évident de mettre ceci en place. Et vous, comment procédez-vous dans vos projets ?

Dans un prochain article, nous vous parlerons de la future version 3 de QGIS et de ses extensions.

Laisser un commentaire

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