Journal OpenJDK est désormais hébergé chez Github tout en se donnant les moyens de l'indépendance

Posté par  . Licence CC By‑SA.
28
11
oct.
2020

Ça y est, le code d'OpenJDK est désormais versionné avec Git et hébergé chez Github ! Cela avait été rapidement abordé dans la dépêche sur Java 15. Cela ne concerne que le code : les tickets et le wiki resteront auto-hébergés sur l'infrastructure OpenJDK.

C'est une grosse nouvelle (à mes yeux du moins) car :

Dans ce journal, je vais juste balayer (et commenter) les informations que j'ai pu glaner dans les JEP. (Pour info, j'ai pas posté vendredi pour que tout le monde sache que je voulais en discuter sérieusement ;-) )

JEP-357 : Migration sur Git

Les raisons données pour migrer sur Git sont :

  • La taille des métadonnées (le dépôt du JDK pèse ~1.2Go sur Mercurial et ~300Mo sur Git)
  • Un gros écosystème d'outils :
    • Tous les éditeurs de texte et IDE ont une intégration de bonne qualité, native ou par plugin
    • Il existe plusieurs clients lourds pour interagir avec un dépôt Git local
  • L'offre d'hébergement (auto-hébergé ou hébergé en tant que service) est plus importante

Dans le cadre de cette migration :

  • un outil a été développé pour changer les messages de commit Mercurial lors de l'import dans Git. Le but était de suivre les bonnes pratiques Git
  • les outils spécifiques au JDK développés autour de Mercurial qui sont quotidiennement utilisés par les développeurs ont été portés sur Git.

Pour ne pas casser les liens, le dépôt Mercurial est toujours en ligne. Un outil de traduction des URL Mercurial vers les URL Git est planifié mais pas encore réalisé (si j'ai bien compris).

JEP-369 : Migration sur Github

Historiquement, les revues de code se font sur un mix de mails et d'un interface Web maison. Les raisons données pour migrer sur Github sont :

  • La performance : en gros, ça marche bien et la disponibilité est bonne
  • L'API : Github propose de très nombreuses API pour interagir avec la plateforme ce qui simplifie l'adaptation des outils interne
  • La communauté :
    • l'argument "classique" qui dit qu'il y a beaucoup de développeurs déjà sur Github et que cela va rendre leur contribution plus simple. Personnellement, je ne suis pas sûr que juste parce que c'est sur Github, les développeurs Java vont subitement se mettre à faire du C++ pour améliorer la JVM.
    • l'argument plus pragmatique (à mes yeux) que l'écosystème Java (dont plusieurs distribution d'OpenJDK) sont déjà sur Github et que cela pourrait renforcer la collaboration (ce qui me parait plus probable que d'avoir de nouveaux développeurs).

Quelque soit les arguments, c'est toujours dommage de voir un gros projet libre aller s'héberger chez Github.

Malgré tout, je trouve cette migration intéressante car ils ont mis en place plusieurs contre-mesures pour éviter de se faire coincer chez Github. Notamment :

  • Duplication dans les mailing lists de toutes les pull request et vice-versa. Cela permet aux contributeurs de continuer à faire les revues via les mailing lists ("comme avant") ou d'adopter Github (voici un exemple de PR où il y a des échanges sur Github et par mail),
  • La mailing list des changements continue d'être alimentée pour éviter de dépendre du flux RSS de Github
  • Utilisation de leur gestion de droits interne (qui est répliquée dans Github) plutôt que de ne s'appuyer que sur Github
  • Utilisation du domaine https://git.openjdk.java.net/ pour rediriger vers le dépôt de source. Les URL vers le code dans les tickets et les mailing lists utilisent ce domaine et non celui de Github, même lorsque le message part de Github.

Pour vous donner un exemple concret, voici :

Et, d'après la JEP, tout cet outillage fonctionne aussi avec Gitlab !

Je suis quand même impressionné par les efforts de cette communauté pour rester indépendante de son fournisseur d'hébergement de code source. A voir dans la durée si cela assure vraiment l'indépendance du projet.

  • # Petit ajout

    Posté par  . Évalué à 4.

    Salut,

    Il existe aussi d'autres moyens d'interroger la communauté, comme un canal IRC.

    De mémoire, ce n'était pas celui-là, je n'y allais uniquement qu'en cas d'extrême besoin. Peut-être que ça a migré aussi.

    Mais à question précise, j'y ai trouvé des personnes qui donnaient des réponses très précises.

  • # travail en double

    Posté par  . Évalué à -2.

    Malgré tout, je trouve cette migration intéressante car ils ont mis en place plusieurs contre-mesures pour éviter de se faire coincer chez Github.

    Je suis partagé sur l'objectif et les moyens.

    1. Ils migrent sur GitHub tout en mettant déjà en place des outils pour se barrer c'est pas un peu comme préparer les papiers du divorce en plein mariage ?
    2. Les moyens qu'ils mettent en place s'apparente à du travail en double et sur le moyen terme ça ne passera pas (mailing liste…). Par ailleurs "Utilisation du domaine https://git.openjdk.java.net/ pour rediriger vers le dépôt de source" n'a aucun intérêt : je comprends qu'ils veulent que ça soit la porte d'entrée mais comme c'est une redirection, l'utilisateur final va bookmarker l'adresse github très rapidement.

    • [^] # Re: travail en double

      Posté par  . Évalué à 8.

      1. Ils migrent sur GitHub tout en mettant déjà en place des outils pour se barrer c'est pas un peu comme préparer les papiers du divorce en plein mariage ?

      Je trouve ça intelligent justement de prévoir de partir, ça veut dire que tu as déjà planifié les coûts (financiers et humains). Tu n’es donc pas enfermé (même si en pratique, c’est difficile de tout prévoir, si tu prévois un maximum, l’inconnu sera plus faible).

      Par ailleurs "Utilisation du domaine https://git.openjdk.java.net/ pour rediriger vers le dépôt de source" n'a aucun intérêt : je comprends qu'ils veulent que ça soit la porte d'entrée mais comme c'est une redirection, l'utilisateur final va bookmarker l'adresse github très rapidement.

      Je ne pense pas que ce soit pour les utilisateurs, qui risque de toute façon d’utiliser leur moteur de recherche, mais plutôt pour avoir des liens dans les documentations qui ne changent pas.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: travail en double

      Posté par  . Évalué à 10.

      Ils migrent sur GitHub tout en mettant déjà en place des outils pour se barrer c'est pas un peu comme préparer les papiers du divorce en plein mariage ?

      Un contrat de mariage, c'est un peu ça, non ?

    • [^] # Re: travail en double

      Posté par  (site Web personnel) . Évalué à 7.

      c'est pas un peu comme préparer les papiers du divorce en plein mariage ?

      Ben justement, ils ne semblent pas vouloir que ce soit un mariage. C’est pas courant de se marier avec le propriétaire de son logement quand on est locataire… À mes yeux c’est plutôt l’espèce de concubinage généralisé et pas vraiment discerné qui semble être la norme sur GitHub qui devrait questionner.

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: travail en double

      Posté par  (site Web personnel) . Évalué à 10.

      1. Ils migrent sur GitHub tout en mettant déjà en place des outils pour se barrer c'est pas un peu comme préparer les papiers du divorce en plein mariage ?

      Je vais te choquer : quand je me suis marié, j'ai bien regardé comment on ferait quand on divorcera.

      Je sais que ça choque plus d'un, mais en fait ça aide en 2 choses :
      - Pendant le mariage aucun des 2 ne doute que l'autre reste pour des problèmes techniques (c'est positif que si on ne veut pas enfermer l'autre, certes, le positif ou négatif dépend donc de vous)
      - En cas de divorce aucun des 2 n'est dans la merde et/ou se bat pour un truc, c'est assez clair de qui a quoi.

      Et c'est bien parce qu'il y a des gens qui ne réfléchissent pas au papiers du divorce au moment du mariage qu'il y a un paquets de mariages malheureux ("je reste car je suis bloqué financièrement, si je me casse je perds tout") et des conflits énormes pendant un divorce ("ça c'est pour moi car c'est moi qui ai payé, ha toi aussi tu dis ça mais non ça ne va pas").

      Bref, tu vois préparer les papiers du divorce en plein mariage comme négatif, perso je le vois comme positif (autant pour un couple que pour le sujet du journal).

      Tu veux un exemple plus acceptable socialement? Dans les avions à chaque décollage on t'explique comment utiliser les issues de secours, qui sont la d'ailleurs, c'est pas comme préparer que ça sera utile? Ben oui… Ca ne veut pas dire qu'on utilisera la chose. On pourrait aussi ne pas mettre d'issues de secours, c'est un choix, perso je préfère les avoir.

      je comprends qu'ils veulent que ça soit la porte d'entrée mais comme c'est une redirection, l'utilisateur final va bookmarker l'adresse github très rapidement.

      Tout n'est pas parfait, mais ça sera moins horrible que sans.

    • [^] # Re: travail en double

      Posté par  . Évalué à 9.

      l'utilisateur final va bookmarker l'adresse github très rapidement.

      C'est pas le problème qu'ils tentent de résoudre je pense. Ce qu'ils veulent c'est que les archives des mailings et les commentaires de commits (ce que tu ne peux pas vraiment modifier) pointent un domaine qu'ils contrôlent.

    • [^] # Re: travail en double

      Posté par  . Évalué à 5.

      et sur le moyen terme ça ne passera pas (mailing liste…)

      Chacun a son avis sur ce mode de revue, mais la mailing list est leur moyen habituel de relire le code.

      Donc, ils n'ont pas mis en place deux nouveaux flux de revue de code mais ils ont maintenu leur flux de revue actuel et ouvert un nouveau flux sur Github. C'est une nuance importante à considérer pour imaginer la tenue dans le temps.

      Par ailleurs "Utilisation du domaine https://git.openjdk.java.net/ pour rediriger vers le dépôt de source" n'a aucun intérêt :

      Désolé de pas avoir détaillé, c'est probablement plus clair en regardant l'exemple de revue que j'ai mis.

      En gros, si tu vas dans le JIRA ou sur les mailings lists, tous les liens vers les revues et les commits sont en git.openjdk.java.net ce qui ne cassera pas l'historique de tout ce qui a déjà été réalisé le jour où ils décident de partir chez Gitlab ou BitBucket.

      Je pense vraiment que l'objectif est de ne pas casser ce qui a été mis dans le bug tracker. Ce n'est pas de maintenir les bookmarks des utilisateurs.

      • [^] # Re: travail en double

        Posté par  . Évalué à 2. Dernière modification le 12/10/20 à 20:57.

        Désolé de pas avoir détaillé, c'est probablement plus clair en regardant l'exemple de revue que j'ai mis.

        En premier lieu, merci pour ton journal et donc le temps passé à rédiger !! C'est clair et je n'ai aucun reproche à faire. J'avais compris le système pour garder les liens d'historique et toussa, mais je reste dubitatif. Copier/copier un lien est tellement simple et rapide que l'adresse en "github.com" finira tôt ou tard par cannibaliser l'ancienne.

        Un contrat de mariage, c'est un peu ça, non

        Bon le rapport avec le contrat de mariage est un troll qui n'a pas pris :smiley_qui_pleure_de_travers: comprenne qui pourra :

        • avant de ma marier : je rembarrais les gens avec leur conseil de contrat de mariage (que des divorcés) en prétextant que si je me mariais, c'était pleinement consentant et partageant toutes mes ressources et biens.
        • après le divorce : à quoi sert le mariage ? bon je déconne mais au final ma vision n'a pas changé. La seule chose vraiment compliquée dans un divorce est l'humain d'autant plus les enfants et aucun contrat ne règlera la question.

        Pour en revenir au sujet principal : beaucoup d'efforts ont été déployés pour assurer la bonne transition et garder les anciennes habitudes et c'est ce que j'ai rappelé avec le titre du thread. Qu'ils conservent des moyens de se détacher à tout moment de github, je le comprends parfaitement mais j'ai le sentiment qu'ils en font beaucoup trop. Est-ce que finalement, ils n'auraient pas mieux fait d'utiliser une forge (ça se dit encore ?) libre ?

        PS : j'ai migré dis adieu à près de 10 ans d'historique de tickets sur une dizaine de projets en migrant de Redmine vers OneDev. Je suis très heureux avec ce 2ème mariage :) mais on ne sait jamais… Certains en ont déjà parlé mais ce qu'il manque à git, c'est un module pour gérer les issues en même temps que le code source. Ainsi lors d'un changement de forge, rien ne serait perdu.

  • # La taille des métadonnées 4 fois plus grosse sur mercurial ?

    Posté par  (site Web personnel) . Évalué à 7.

    Je suis étonné par la taille du stockage nécessaire pour conserver le même historique et les même métadonnées entre mercurial et git. Quelqu'un aurait plus d'infos sur le sujet ?

    • [^] # Re: La taille des métadonnées 4 fois plus grosse sur mercurial ?

      Posté par  (site Web personnel) . Évalué à 10.

      Mercurial utilise un système "append-only", où tout ce qui est écrit reste ad-vitam eternam. C'est une bonne propriété de pas mal de points de vues, par exemple c'est incremental-backup friendly. Git s'autorise à re-compresser a posteriori (git gc & cie) et du coup a pas mal d'opportunités d'optimisations en plus. Git peut delta-compresser (= ne stocker que le diff entre deux objets) n'importe quoi avec n'importe quoi au moins en théorie. Il s'autorise à utiliser un algo un peu bourrin, vu que la compression peut se faire en tâche de fond, ou sur les serveurs de l'hébergeur donc ça ne gène pas au quotidien le développeur. Ce que Git stocke c'est un ensemble d'arbres de delta, la racine de chaque arbre est un fichier stocké complètement, et les autres nœuds sont représentés par le delta avec leur père, ça permet de stocker très peu de fichier complètement tout en gardant des chaînes de delta de longueur raisonnables.

      Un truc qui peut jouer aussi c'est que le format "pack" de Git utilise peu de fichiers (de grosse taille), alors que Mercurial utilise beaucoup de fichiers relativement petits. En général le filesystem alloue des fichiers par multiples de 4Ko, donc le stockage en petits fichiers fait perdre un peu de place par fichier.

      (Disclaimer : je n'ai pas regardé Mercurial depuis des années, y'a peut-être des choses qui ont changé depuis)

  • # Bot openjdk

    Posté par  . Évalué à 4.

    Cette migration a aussi été l’occasion de développer un bot pour la gestion des pull request. Il fait plein de choses : lancer les tests, ajouter des tags, etc. Je vous laisse regarder les commentaires sur les PR dont voici un exemple : https://github.com/openjdk/jdk/pull/393

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.