Ç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 :
- La réflexion autour de cette migration (nom de code Skara) a été lancée il y a plus d'un an.
- Pour celles et ceux qui ne le savaient pas, le code était versionné avec Mercurial et auto-hébergé.
- A 1ère vue ou en lisant juste le communiqué de Github, on pourrait croire qu'OpenJDK vient d'abandonner son indépendance
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 _kaos_ . É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.
Matricule 23415
# travail en double
Posté par stopspam . Évalué à -2.
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 claudex . Évalué à 8.
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).
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 aiolos . Évalué à 10.
Un contrat de mariage, c'est un peu ça, non ?
[^] # Re: travail en double
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
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 Zenitram (site web personnel) . Évalué à 10.
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.
Tout n'est pas parfait, mais ça sera moins horrible que sans.
[^] # Re: travail en double
Posté par barmic 🦦 . Évalué à 9.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: travail en double
Posté par bbo . Évalué à 5.
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.
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 stopspam . Évalué à 2. Dernière modification le 12 octobre 2020 à 20:57.
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.
Bon le rapport avec le contrat de mariage est un troll qui n'a pas pris :smiley_qui_pleure_de_travers: comprenne qui pourra :
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 LeBouquetin (site web personnel, Mastodon) . É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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La taille des métadonnées 4 fois plus grosse sur mercurial ?
Posté par Matthieu Moy (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)
[^] # Re: La taille des métadonnées 4 fois plus grosse sur mercurial ?
Posté par bbo . Évalué à 2.
Comme LeBouquetin, j'avais été étonné par l'ordre de grandeur, mais sans creuser.
Merci pour ces informations !
# Bot openjdk
Posté par Nonolapéro . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.