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

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

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

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.

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.

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.

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.

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

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.

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 :

• l'équipe Skara s'est assurée du bon fonctionnement avec Gitlab par exemple ;
• le gestionnaire de ticket reste Java Bug System (JBS) ;
• les liens sont neutres (sans usage de github.com). Par exemple, l'URL officielle est https://git.openjdk.java.net/jdk. Elle redirige vers https://github.com/openjdk/jdk. Ce type d'URL est utilisé dans le workflow du projet. Ci-dessous un 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.

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

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 :

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 :

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