Projet Skara, C’est quoi donc ?

Contexte

Plusieurs projets sont en cours au niveau d' OpenJDK. L’objectif d’un projet est de fournir un travail collectif pour produire un artefact spécifique. Celui peut être du code, de la documentation, ou n’importe quel matériel. Commençons par le projet Skara.

logo projet skara
Figure 1. Logo du projet Skara

En effet ce dernier est sous les feux des projecteurs avec deux JEP dans le JDK 16.

Via ces deux JEP, nous pouvons voir que le projet a procédé par étape : choix vers un nouveau gestionnaire (si besoin), puis d’un hébergeur.

Historique

Le projet a été créé en septembre 2018 (Welcome to skara-dev)

L’objectif du projet est d’étudier les alternatives à Mercurial pour le gestionnaire de sources et les différents fournisseurs. Ce qui intéressant dans la démarche, c’est qu’il dissocie le choix de gestionnaire de sources et le choix de l’hébergeur. Le choix de Mercurial avait été fait par Sun Microsystems en 2006.

Il faut noter qu’il y a eu la JEP 296 inclus dans le JDK 10 (Mars 2018) sur la consolidation des dépôts en un seul. En effet, le code du JDK était réparti sur différents dépôts : racine, corba, hotspot, jaxp, jaxws, jdk, langtools et nashorn.

depot mercurial openjdk jdk8
Figure 2. Dépôt mercurial du JDK 8

L’objectif de ce regroupement est de simplifier le travail des développeurs. En effet, un correctif impliquait très souvent plusieurs dépôts. Les développeurs devaient réaliser plusieurs 'commit' sur différents dépôts. Cela compliquait leur travail et pouvait être une source d’erreurs.

astuce Il est à noter que Nashorn introduit dans le JDK 8 n’est plus fourni dans le JDK depuis la version 15, mais il reste en tant que projet autonome (dépôt du projet).


Passage de Mercurial à Git (Objectifs)

Migration de tous les référentiels OpenJDK

Cela consiste à migrer tous les référentiels mono-repo vers Git. Cela signifie que les dépôts à partir du JDK 10 sont disponibles sous GIT (cf la section Historique).

avertissement Nous retrouvons l’intérêt du travail préparatoire consistant à fusionner plusieurs dépôts en un seul (JEP 296).

Préserver l’historique

Au delà, de déposer l’ensemble des sources sur le nouveau gestionnaire de sources, la préoccupation de l’équipe a été de préserver l’historique. Dans ce sens, un outil de traduction de hash Mercurial vers un hash Git a été développé (cf. section suivante).

Porter les outils

C’est aussi les modifications des outils utilisés par le projet afin qu’ils fonctionnent avec git.

  • git-jcheck : Outil jcheck pour être compatible avec GIT

  • git-webrev : Outil webrev pour être compatible avec GIT

  • git-defpath : Outil defpath pour être compatible avec GIT

  • git-skara : Informations sur les outils Skara CLI

  • git-info : Montrer les informations OpenJDK au sujet des commits : lien avec les fiches JBS, les auteurs, les contributeurs.

C’est aussi des nouveaux outils, avec par exemple des outils pour échanger avec un fournisseur externe

  • git-fork : "Forker" un projet d’un fournisseur externe vers un espace personnel, et le cloner optionnellement.

  • git-sync : Synchroniser le "fork" personnel avec l’état courant du dépôt d’origine.

  • git-pr : Interagir avec les "pull requests" avec un fournisseur externe GIT.

  • git-token : Interagir avec le gestionnaire pour obtenir un token d’accès.

  • git-translate : Traduire un hash Mercurial en Hash GIT (cf. section précédente).

  • git-trees : Exécuter une commande GIT dans une arborescence de dépôts.

  • git-publish : Publier une branche locale vers un dépôt distant.

astuce L’équipe a rendu disponible les différents outils de Skara sous licence GPL 2.0. Ils sont accessibles à l’adresse sur le dépôt GIT du projet. Cela permet d’y contribuer, de l’utiliser ou de s’en inspirer pour ces propres projets.

Parmi les outils, il existe aussi des outils coté serveur. Voici quelques exemples :

  • mlbridge : Pont entre les messages de liste de diffusion et les "pull requests".

  • notify : Envoyer des mails de notifications quand les dépôts sont mis à jours.

  • pr : Ajouter le support du workflow OpenJDK pour les "pull requests".

  • forward : Faire suivre les commits sur plusieurs dépôts.

  • mirror : Faire un dépôt miroir

  • merge : Fusionner des commits entre différents dépôts et/ou branches.

Passage de Mercurial à Git (Motivations)

Taille des méta-données

Les méta-données sont de plus en plus volumineux (1.2 Go sous Mercurial, 300 Mo sous Git seulement lors des tests). Cela devenait de plus en plus contraignant pour les développeurs, notamment sur les phases de synchronisation.

Outils

De nombreux outils supportent GIT comme les éditeurs Emacs, Vim ou VSCode qui le supporte nativement. De même, l’ensemble des IDE (Eclipse, Netbeans et Intellij) le prennent en charge. Là encore, si je prends Eclipse IDE, le support de GIT est disponible tout de suite après l’installation, sans la nécessité d’un plugin supplémentaire.

Hébergement

Il existe plusieurs solutions d’hébergement comme Gitlab, Sourceforge et Github.

Communauté

Mercurial est aussi considéré comme un frein à la contribution. Au dela des aspects techniques, ce gestionnaire de sources est peu répandu. Donc, les nouveaux contributeurs doivent passer par une étape supplémentaire en apprenant l’usage de l’outil.

Migration sous Github

Comme vu précédemment, une des forces de GIT est d’avoir plusieurs fournisseurs.

Le fournisseur retenu

Le projet Skara a donc évalué les différentes solutions d’hébergement. C’est Github qui a été retenu. La grande communauté d’utilisateurs et le partenariat entre Oracle et Microsoft (propriétaire de Github) ont notamment joué en faveur de cette décision.

Il est important de noter que le choix du fournisseur n’implique pas d’adhérence. Nous pouvons voir que :

message exemple commit
Figure 3. Exemple de mail suite à un commit

En cliquant sur le lien https://git.openjdk.java.net/jdk/commit/db5da961, nous arrivons finalement sur la page de commit de github.

De même, une url neutre est utilisée pour réaliser la revue de code d’une "pull request". Cette dernière redirige vers la page correspondante à la "pull request".

  • Les outils cités plus haut permettent d’interagir avec le fournisseur externe, github en l’occurrence.

Etapes préparatoires

Certains projets sont passés sous github en avance de phase. Cela a permit de tester en condition réelle les outils et les workflow mis en oeuvre. Ainsi, le projet a bénéficié de retour d’expérience et des ajustements ont pu être réalisés. Par exemple, le projet Loom a été l’un des premiers projets en août 2019

projet loom moving to github

La bascule

La migration a été effectuée du 04 au 05 septembre 2020. Voici un résumé avant et après les opérations :

  • Avant la migration du 04 septembre,

 — Mercurial : Lecture / Ecriture

 — Github : Lecture seule

  • Après la fin des opérations le 5 septembre

 — Mercurial : Lecture seule

 — Github : Lecture / Ecriture

Nous pouvons le voir clairement au niveau des dépôts. Il est bien indiqué que le dépôt jdk11u reste un dépôt miroir du dépôt Mercurial. En revanche le dépôt JDK n’est plus un miroir mais bel et bien le dépôt principal :

github jdk jdk11u
Figure 4. Dépôt disponible sur github

Depuis cette date, toutes les modifications passent par des "pull request" depuis github (via l’interface ou les outils). La première PR n’a pas tardé car elle a été réalisée dès le 6 septembre 2020 :

PremierePR into JDK16
Figure 5. Première PR via github

Suite à la bascule, voici le lien vers la première "pull request" https://github.com/openjdk/jdk/pull/23.

Conclusion

Même si nous ne sommes pas contributeur d' OpenJDK, c’est intéressant de voir comment fonctionne l’équipe et tout le travail qui est réalisé.

Dans ce sens, la PR #1891 est intéressante car elle permet de voir le workflow et les outils mentionnés dans ce billet :

Cela permet aussi de mieux comprendre les étapes de la sortie d’un nouveau JDK. En effet, nous avons plusieurs paliers comme "Rampdown", "Release Candidate". Par exemple, l’agenda prévu pour le JDK 16 est le suivant :

schedule jdk16
Figure 6. Agenda du JDK 16

Nous pouvons lire qu’au niveau du "Rampdown Phase1", nous avons une précision "Fork from main line". Et c’est bien ce qui se passe, un "fork" du dépôt principal jdk est réalisé pour créer un nouveau dépôt spécifique jdk16.

github jdk16
Figure 7. Dépôt du JDK16

Nous pouvons espérer que le passage à Git et notamment à Github permettent d’avoir de nouveaux contributeurs. Pourquoi pas vous ?