IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel pour tout comprendre sur le projet Skara : abandon de Mercurial pour Git

Cet article s'intéresse au projet Skara. L'objectif du projet est d'étudier les alternatives à Mercurial pour le gestionnaire de sources et les différents fournisseurs. Ce qui est 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.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez Donner une note  l'article (5).

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. 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-ci peut être du code, de la documentation, ou n'importe quel matériel. Commençons par le projet Skara.

Image non disponible
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.

II. 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 est 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 incluse 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.

Image non disponible
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.

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).

III. Passage de Mercurial à Git (Objectifs)

III-A. Migration de tous les référentiels OpenJDK

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

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

III-B. 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).

III-C. 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.

L'équipe a rendu disponibles 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 ses propres projets.

Parmi les outils, il existe aussi des outils côté 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 à jour ;
  • 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.

IV. Passage de Mercurial à Git (Motivations)

IV-A. Taille des métadonnées

Les métadonnées sont de plus en plus volumineuses (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.

IV-B. Outils

De nombreux outils supportent GIT comme les éditeurs Emacs, Vim ou VSCode qui le supportent 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.

IV-C. Hébergement

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

IV-D. Communauté

Mercurial est aussi considéré comme un frein à la contribution. Au-delà 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.

V. Migration sous Github

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

V-A. 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 :

Image non disponible
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 correspondant à la « pull request ».

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

V-B. Étapes préparatoires

Certains projets sont passés sous github en avance de phase. Cela a permis de tester en condition réelle les outils et les workflows mis en œuvre. Ainsi, le projet a bénéficié de retours 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

Image non disponible

V-C. La bascule

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

  • avant la migration du 4 septembre :

    • Mercurial : lecture / écriture
    • Github : lecture seule ;
  • après la fin des opérations le 5 septembre :

    • Mercurial : lecture seule,
    • Github : lecture / écriture.

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 :

Image non disponible
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 :

Image non disponible
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.

VI. 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 :

Image non disponible
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.

Image non disponible
Figure 7. Dépôt du JDK16

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

VII. Remerciements

Cet article a été publié avec l'aimable autorisation de Lilian Benoit. L'article original (Projet Skara, C’est quoi donc ?) peut être vu sur le blog https://www.lilian-benoit.fr/.

Nous tenons à remercier Claude Leloup pour sa relecture attentive de cet article et Winjerome pour la mise au gabarit.

VIII. Références

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2021 Lilian BENOIT. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.