Bonjour Nal,
Je te partage un communiqué de l'April intéressant qui appelle à la création d'une forge publique par l’État.
L'intention est louable : les grosses forges américaines comme github ou gitlab sont devenus tellement centrales dans le monde du logiciel qu'il est difficile de construire un produit qui n'en soit pas dépendant de façon directe (hébergement sur ces plateformes) ou indirectes (récupération de dépendances).
Toutefois je me demande si le mieux ne serait pas de multiplier les petites forges (par exemple avec des logiciels comme gitea, gogs, forgejo, sourcehut, gitlab community…) pour ne pas simplement remplacer une dépendance à un gros acteur privée par une dépendance à un gros acteur public.
Pour le secteur public, cela pourrait une forge par projet, par administration, par ministère, par région…
Dans les entreprises, la question se pose aussi souvent : une grosse forge pour tout le groupe versus des petites forges par filiales, services, voire projet ?
Et toi Nal? Tu es plutôt centralisateur ou décentralisateur ?
# Besoin d'interopérabilité
Posté par Christophe . Évalué à 10 (+9/-0).
En fait ce qui est gênant avec les multiples forges, c'est le manque d'interopérabilité. Aujourd'hui, si je veux faire 3 petits patchs sur 3 projets hébergés par Github, Gitlab et Sourcehut, je dois me créer un compte par forge juste pour leur proposer chaque patch ou même ouvrir un ticket.
J'aimerais bien avoir la possibilité d'avoir mon fork sur la forge de mon choix, et envoyer mes changements upstream inter-forge.
Git propose l'envoi par email, mais franchement pour collaborer sur un patch c'est très peu ergonomique.
Il manque donc un protocole de collaboration inter-forges pour que la décentralisation devienne une réalité. Mais même pour une même forge, je ne crois pas qu'on puisse collaborer entre les différentes instances… Ce serait déjà un bon début !
[^] # Re: Besoin d'interopérabilité
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+10/-0).
Ce protocole existe :-)
https://forgefed.org/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Besoin d'interopérabilité
Posté par Misc (site web personnel) . Évalué à 9 (+8/-2).
Ce projet ne décolle pas. Le premier commit date d'il y a 8 ans, en mars 2017. Il n'y a toujours rien de viable maintenant, et le projet vient tout juste d'avoir un financement de NlNet (NlNet et co qui servent quand même souvent de vache à lait pour avoir des thunes et rien faire de substantiel, genre le projet fedeproxy ).
Le code initial pour Forgejo (qui a été forké à la base pour "officiellement" rajouter la fédération, puis ensuite officiellement pour des raisons de financement du projet, et officieusement parce que le leader du fork se fache avec beaucoup de gens, surtout quand il a pas ce qu'il veut) avait été fait par un doctorant du MIT qui passait dans le coin, et y a pas eu grand chose de nouveau depuis.
Quand on regarde le ticket de 2023, on voit quand même que y a toujours des projets qui se lancent, des grands mouvements, des POCs sur des bouts séparés, et qu’après des années de discussions et de code, et de patchs, tout ce qu'il y a à montrer, c'est de laisser des étoiles de façon fédéré (et juste ajouter des étoiles, pas en retirer, c'est encore WiP).
Et on va me dire "oui, mais c'est des volontaires, tout ça, tout ça". Et je dirait "bullshit".
J'utilise Gotosocial, qui est un serveur ActivityPub (comme la federation de forge), en golang (commegitea/forgejo) fait par des volontaires dans leur garage (moins comme forgejo, qui a des gens payés pour bosser dessus via des grants ou via leur boite), qui a commencé il y a 4 ans (donc 2 ans après le document initial pour forgefed), et qui est fonctionnel (contrairement à la fédération de forge).
Donc bon, si on compare 2 projets dans le même domaine, avec le même langage, on peut voir qu'il y en a qui publie du code et l'autre non, en ayant eu 2 fois plus de temps.
[^] # Re: Besoin d'interopérabilité
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0).
En plus de ton analyse, c'est peut être que la fédération de forge est beaucoup difficile que ce que les devs pensaient au départ :-)
Et si je voulais troller sur la comparaison avec Gotosocial, j'ajouterais que la fédération de réseaux sociaux pour autistes égocentriques est plus facile à implémenter :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Besoin d'interopérabilité
Posté par Misc (site web personnel) . Évalué à 10 (+7/-0).
Ce qui est difficile, c'est surtout de savoir ce qu'on veut dire par "fédération de forge", car j'ai le sentiment que personne ne définit vraiment les choses et personne ne pose les questions difficiles, et tout le monde rajoute son petit truc. Et c'est pour ça que ça n'avance pas.
La raison d'avoir uniquement les étoiles, c'est parce que c'est le truc ou tu as le moins de latitude et de choix. Le décompte ne change rien de substantiel, n'a aucun impact si il est faux et n'est qu'un nombre attaché à un dépôt.
Par contre, si on commence à parler de choses plus complexes comme les bugs/issues/PR, ça devient d'un coup plus compliqué.
Par exemple, il y a des gens qui voudraient que la fédération de forge soit totalement décentralisé (comme un salon matrix), d'autres qui voudraient simplement avoir un login fédéré (comme une liste de discussion, ou une communauté lemmy).
Suivant ce que tu vises, faut se demander ou se passe la collaboration (eg, qui a la version de référence de la discussion), la forge upstream, ou la forge locale ?
Dans la vision 2 (login fédéré), la réponse est "la forge upstream".
Il se passe quoi quand il y a des conflits d'humain, qui décide de fermer la discussion ? Comment tu fait pour bosser si le projet est sur la forge A, tu es sur B, et quelqu'un de C vient, avec C bloqué par la forge B (la tienne) mais pas la forge A ? (tout rapport avec du dramastodon passé n'est pas fortuit).
Si la forge centrale est en panne, il se passe quoi ? Qui décide du numéro de ticket quand on en ouvre un ? Est ce que les tickets sont par dépôt, comme maintenant, ou attaché par magie au code (et donc synchro comme le code, avec merge conflict, etc)
Et vu que ActivityPub, c'est simplement de la publication de messages (il n'y a pas automatiquement de réconciliation comme avec le protocole Matrix), il se passe quoi quand des bouts sont perdus ?
Et si la réponse est "on s'en fout, on synchronise via F3", alors pourquoi se faire chier à faire un vocabulaire vu que la synchro va éventuellement arriver.
Maintenant, si on parle de la vision décentralisé comme Matrix, pourquoi ne pas avoir gardé le protocole de Matrix comme au début du projet Forgeflux.
Pourquoi faire un protocole d'export quand ce qu'il faut, c'est un système d'operational transform (comme Google Wave et par la suite etherpad, google docs, etc)
Donc si la vision est "comme Lemmy" et de tout centraliser sur un serveur d'origine, pourquoi se faire chier avec ActivityPub quand on peut:
- mettre un cron sur git clone (gitea le fait déjà, je fait des copies de mes applis en local depuis gitlab/github/framagit, ou l'inverse, je pousse via cron)
- déléguer l'authentification pour écrire des issues via openid ou n'importe quoi d'autre
Car fondamentalement, on pourrait juste avoir nos emails/mxid/id xmpp/id mastodon comme identifiants, et mettre une forme de login par dessus. Pas besoin de faire tout un vocabulaire ActivityPub pour ça, faut juste changer le format des logins et des urls.
Et si c'est la vision "comme Matrix", pourquoi avoir pris ActivityPub et pas Matrix ?
Comme visiblement, c'est AP qui a été pris, donc j'en conclus que des gens ne veulent pas centraliser comme je l'indique (sinon, ça serait plus simple), ni faire comme Matrix (sinon, tu mets juste une passerelle git vers matrix).
Par exemple, si je reviens sur le format de stockage F3, c'est utile, mais ça n'est pas spécialement une question de fédération en soi, c'est juste se donner les moyens techniques de claquer la porte pour divers raisons (pratique quand on ne sait pas gérer sa frustration et qu'on a l'habitude de le faire, par exemple). Bien sur, ç'est à la fédération ce que le Brexit est à la gouvernance fédéré de l'Europe, donc je peux voir le rapport.
On a pas besoin d'un format d'export pour la fédération (le SMTP n'utilise pas ça, par exemple) et c'est pour moi un indicateur qu'il y a une vision autre que la simple fédération si on rajoute autre chose de périphérique.
Autre exemple, un des cas d'usage qui avait été discuté à l'époque, c'était d'utiliser la fédération pour éviter les soucis de blocage de l'OFAC vis à vis des fournisseurs US (les nationaux iraniens n'avaient pas le droit d'utiliser Github, ou certains citoyens russes).
Mais du coup, en tant qu'objectif, comment ça se positionne vis à vis de demandes futures et probables de ne pas interagir avec tel ou tel personne pour divers raisons ? Car si tu permets de bloquer un spammeur, tu peux aussi bloquer l'Iran (voir même, c'est plus facile de bloquer l'Iran que les spammeurs).
Et puis dans tout ça, quid de la modération ?
Il y a déjà une tonne de spam sur les forges publiques, en quoi proposer un moyen de contourner l'éventuelle vérification au login va aider à ce niveau ? Surtout que Codeberg a bien montrer que niveau modération, il y a encore des trous et c'était pas la priorité (vu qu'il y a fallu avoir un souci pour avoir une réunion sur "comment limiter les APIs").
Bref la fédération, je vais faire comme l’apôtre Thomas, je vais y croire quand je vais la voir.
[^] # Re: Besoin d'interopérabilité
Posté par orfenor . Évalué à 4 (+2/-0).
Il me semble que Fossil est fédéré, non ? il y a déjà tout dedans et ça marche.
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Tu compliques un peu, décentralisé ne veut pas dire avoir les commentaires distribués partout et reconstruire un truc cohérent après coup (ça peut vouloir dire ça si on veut, mais ça peut être beaucoup plus simple).
Dans le cas de XMPP, c'est le serveur pubsub du dépôt principal qui gère les tickets et tout (numéro de ticket, de merge request, etc), c'est un peu comme une mini forge centralisée. Donc tu peux modérer en cas de comportement incorrect ou de spam.
L'intérêt par rapport à une forge centralisée comme Github c'est que:
c'est un compte XMPP, donc l'authentification est gérée par le mécanisme XMPP, donc le serveur de la personne qui contribue. Pas besoin de créer un compte sur chaque forge.
Si une forge veut supprimer un projet (comme c'est déjà arrivé plusieurs fois sur Github, avec
yt-dlpar exemple), il est très facile de le passer sur une autre, et les contributeurs et contributrices peuvent continuer sans changer leur compte (en changeant uniquement l'adresse de la forge).Les tickets peuvent être clonées et mis sur une autre forge, c'est de simples nœuds pubsub à cloner.
Git et Mercurial sont déjà décentralisés, donc pareil, il suffit de cloner pour aller ailleurs.
Bref, sur ta forge tu es chez toi et tu la gères comme tu l'entends. Comme une mini forge centralisée, à la grosse différence près c'est qu'il est très facile de passer sur une autre en cas de problème (technique, politique, etc.), sans avoir à recréer de compte pour les contributeurs et contributrices.
Github a un effet réseau énorme qui limite l'intérêt des petites forges parce que les gens ont la flemme de créer un autre compte, et que ça n'est pas possible/simple de faire des liens entre des tickets/des pull requests/autre sur d'autres forges.
Avec XMPP, chacun peut faire sa propre forge, et c'est l'équivalent un gros service en groupant plein de petits , on peut communiquer et lier facilement les choses entres elles. Je suppose que ce qui est fait avec ActivityPub est plus ou moins similaire (mais encore une fois, je n'ai pas suivi de près, vu que la roue est plus ou moins réinventée, encore une fois).
[^] # Re: Besoin d'interopérabilité
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Si je comprends bien, tu perds tout le contenu à moins que tu ai fait une copie préalable ?
Ça va paraître provocateur mais est-ce que c’est pas plus simple :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 06 mai 2025 à 12:36.
Le format d'export standard, c'est la spéc XMPP.
OAuth (qui est d'ailleurs supporté par XMPP) ne gère que l'authentification, et souvent tu as un compte en local qui est recréé. Ça n'est pas pareil qu'avoir tout le système décentralisé, avec les informations d'identité (vCard, avatar, etc), les clefs de chiffrement, les permissions, la possibilité de lier facilement des éléments ailleurs, l'inscription et les notifications, etc.
Si je pouvais me connecter à Github avec mon compte linuxfr, ça ne changerait pas grand chose au fait que je ne peux pas facilement forker sur un autre serveur, lier un ticket, etc.
[^] # Re: Besoin d'interopérabilité
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 06 mai 2025 à 11:37.
Merci pour ce panorama de la fédération de forge, je comprends mieux pourquoi ça a du mal à avancer :-)
En te lisant, j'ai l'impression que la vision "à la matrix" n'est pas souhaitable : elle entraîne des problèmes pratiques (modération) et techniques (scalabilité) trop difficiles à gérer pour des petites forges : on aboutirait à une fédération centrée sur quelques grosses forges, une situation pas très différente de celle qu'on voudrait éviter avec la décentralisation :-)
Peut être qu'un bon SSO et des protocoles/formats pour migrer facilement sont largement suffisants.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10 (+16/-1).
Alors je suis moi même bénéficiaire de subvention NLnet/NGI (j'en ai eu plusieurs), donc je ne suis pas neutre. Mais dire un truc pareil c'est franchement insultant autant pour le boulot de fou qu'ils et elles font, et pour les bénéficiaires.
Quand une subvention est acceptée (après une validation de plusieurs mois en 2 étapes, 1 première sélection suivie d'une deuxième avec des questions aux projets), on a un appel en visio pour présenter les choses, et on se met d'accord sur un "Memorandum of Understanding". Ça n'est pas un contrat (on n'est pas employé·e·s) mais c'est un accord sur les étapes à faire avec des livrables (une merge-request par exemple) et les sommes demandées. Ces étapes sont proposées par le projet et validées par l'équipe de NLnet, et la sommes des étapes doit correspondre au total accordé.
On ne reçoit rien si on ne fait rien, il faut finir une étape, et ensuite c'est vérifié, et enfin payé, ce qui peut mettre jusqu'à 3 semaines (et je me suis d'ailleurs plusieurs fois retrouvé mal parce que j'avais sous estimé — Comme tout développeur·se qui se respecte — le temps qu'il fallait pour une étape). Ça arrive d'ailleurs qu'on ne puisse pas finir toutes les étapes avant la fin du programme, et alors une partie de la somme accordée est perdue (ça m'est arrivée sur ma première subvention).
Alors il est fort possible, que sur tous les projets financés, certains n'ont pas fait toutes les étapes, et la subvention n'a pas donné ce qui était attendu (encore une fois ça n'est pas un contrat, il n'y a pas d'obligation, on ne reçoit juste par l'argent si les choses ne sont pas faites). Mais je vois énormément de projets, dont certains que j'utilise régulièrement, qui ont pu se développer grâce à NLnet/NGI, et d'ailleurs dans le monde XMPP il y a pas mal de spécifications qui ont vu le jour grâce à ça, et plusieurs logiciels qui ont pu se développer.
NLnet/NGI ont donné et donnent toujours un aide énorme à des tonnes de projets, et il y a de bonnes chances que celles et ceux qui me lisent en bénéficient via un projet financé.
C'est une des meilleures choses qui est arrivée au logiciel libre ces dernière années (et je suis loin d'être le seul à le dire).
[^] # Re: Besoin d'interopérabilité
Posté par Misc (site web personnel) . Évalué à 6 (+5/-2).
Je sais comment ça marche, j'ai vu ça de l'intérieur.
Quand je dit que la fédération de forge sert à faire miroiter auprès de NGI, c'est parce qu'avec le recul, il y a quand même masse pompage de fric sur le sujet:
En 2021 pour fedeproxy ( https://www.ngi.eu/funded_solution/ngi-dapsiproject-16 et https://dapsi.ngi.eu/hall-of-fame/fedeproxy/ ) et pour Gitea ( https://github.com/go-gitea/gitea/issues/16827 ).
En 2022 pour Forgejo ( https://nlnet.nl/project/Federated-Forgejo/ ), et Forgefed ( https://www.ngi.eu/blog/2022/11/24/how-ngi-supports-open-interoperable-decentralised-and-trust-based-internet-applications-through-fediverse-projects-like-mastodon/ )
En 2023 pour Forgeflux ( https://nlnet.nl/project/ForgeFlux/ et https://ngi.eu/funded_solution/forgeflux/ ).
En 2024, y a eu 2 autres grants sur Forgejo ( https://forgejo.org/2024-12-monthly-update/#sustainability ), des tentatives via Sovereign Tech Fund ( https://codeberg.org/forgejo/sustainability/issues/84 ), et encore une sur Forgefed ( https://nlnet.nl/project/ForgeFed-frontend/ ).
Et visiblement, on retente encore en 2025 ( https://codeberg.org/forgejo/sustainability/issues/74 ).
C'est bien de chercher de l'argent, je comprends bien que tout le monde n'a pas la chance que j'ai d'en avoir, mais je crois aussi que le but, c'est aussi de publier du code à un moment.
Et à la rigueur, si des gens trouvent le moyen de financer leur travail comme ça, tant mieux. Mais tout le temps et l'argent qui part dans ça, c'est du temps qui part pas dans des personnes comme toi qui me semble plus productive.
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Ah tu parles spécifiquement des projets liés à ça, je pensais que tu critiquais tout le système NLnet/NGI. Dans le cas précis des forges basées sur ActivityPub, je n'ai pas suivi de près (j'avais été contacté vite fait quand ça a été commencé, puis XMPP ne les intéressait illes ont préféré refaire avec AP).
S'il y a de la demande, je ne serais pas contre intégrer ça à la passerelle AP<=>XMPP un jour (si c'est raisonnablement faisable), mais en attendant, XMPP rempli toutes les cases au moins pour moi.
[^] # Re: Besoin d'interopérabilité
Posté par Alcyone . Évalué à 10 (+9/-0). Dernière modification le 05 mai 2025 à 10:06.
C'est l'idée de projets comme ForgeFed (ActivityPub) ou encore Radicle (P2P).
EDIT: devnewton a été plus rapide ;-)
Alcyone
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
C'est ce que je fais avec XMPP pour mon projet Libervia depuis des années : une forge (enfin pour le moment des tickets et un système de merge requests) décentralisée, et accessible avec tout compte XMPP. C'est basé sur Pubsub, ça veut dire que de nombreuses chouette fonctionnalités sont possibles, comme le chiffrement de bout en bout (pour faire un ticket sensible, comme un rapport de bogue sur une faille de sécurité par exemple).
L'idée a été reprise pour ActivityPub avec ForgeFed. J'ai également une passerelle ActivityPub <=> XMPP, il est possible, si je trouve les ressources, d'ajouter une compatibilité pour ces fonctionnalités à terme.
[^] # Re: Besoin d'interopérabilité
Posté par Alcyone . Évalué à 7 (+6/-0).
Honnêtement (et je salue (à toi ;-) ) ton initiative), je pense que la compatibilité ActivityPub/XMPP est probablement le meilleur moyen pour que le projet prenne à mon sens et cela peut aussi redonner un peu de vent à XMPP : possibilité de fédération de forge avec tout l'écosystème de chat d'XMPP (voire microblogging si l'on pense à Movim).
Alcyone
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Libervia gère aussi le blogging/microblogging, et c'est déjà implémenté dans la passerelle AP<=>XMPP (les messages directs sont convertis en messages de chat, les message publics sont convertis en blogs XMPP et vice versa).
[^] # Re: Besoin d'interopérabilité
Posté par Alcyone . Évalué à 5 (+4/-0).
Tout à fait ! Je m'en suis rappelé après délai de modification de mon message '
Est-ce similaire à celui de Movim en revanche ? Question qui me taraude…
Alcyone
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
On utilise les mêmes extensions oui, et on se connaît, si quelque chose ne fonctionne pas, on cherche à corriger.
[^] # Re: Besoin d'interopérabilité
Posté par Christophe . Évalué à 6 (+4/-0).
Oui, ActivityPub me semble être une bonne voie à explorer pour résoudre ce problème, heureux de voir que des gens se penchent déjà sur le problème :)
[^] # Re: Besoin d'interopérabilité
Posté par jnanar (site web personnel) . Évalué à 7 (+5/-0).
Goffi avait commencé un travail dans ce sens. C'est basé sur XMPP comme c'est son protocole de prédilection et j'avais eu l'occasion de tester. C'est décrit ici sur son blog en français et dans la doc en anglais.
https://upload.libervia.org/b/68025fd2-6cfe-462a-948c-c170c344468b?lang=fr
https://libervia.org/__b/doc/backend/libervia-cli/merge-request.html
Pour l'instant, ça ne fonctionne qu'avec Mercurial mais ça donne une idée de ce que ça pourrait donner. Pour l'instant les performances de Libervia, l'outil qui les affiche ne sont pas terribles mais l'outil en cli était plus rapide dans mes souvenirs.
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Je suis justement en plein redesign, et il est fort probable que je passe finalement à Git, de plus en plus d'outils ne prenant en compte que Git (notamment
uvqui devient la référence en Python). C'est dommage, Mercurial est vraiment un bon outil, et plus intuitif que Git.[^] # Re: Besoin d'interopérabilité
Posté par orfenor . Évalué à 3 (+1/-0).
Et pijul ?
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Alors je fais en général les choses de manière générique, de façon a pouvoir changer de backend, et Libervia est extensible (je suis en train de travailler sur cette partie là aussi, et sur la doc) donc il peut il y avoir des contributions tierces et il sera sans doute possible de gérer d'autres VCS.
Par contre, si je veux passer à Git, c'est parce que c'est le VCS de référence incontestable. Pour d'autres options, ça ne sera pas dans l'immédiat, je n'ai pas actuellement les ressources (je suis complètement sous l'eau).
[^] # Re: Besoin d'interopérabilité
Posté par orfenor . Évalué à 3 (+1/-0). Dernière modification le 05 mai 2025 à 22:48.
Oh je sais bien, c'était pour indiquer un gestionnaire de version plus intuitif que Git. J'espère que tu vas y arriver, j'apprécie beaucoup ce que tu fais. Je sais comme ça peut-être épuisant de porter un projet à bout de bras. Courage, Libervia mérite tes efforts!
[^] # Re: Besoin d'interopérabilité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Merci :)
[^] # Re: Besoin d'interopérabilité
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3 (+2/-0).
Je pense que le souci vient du fait que git a été imaginé par Linus pour gérer le noyau, dont les contributions sont également gérées par des listes de diffusion. L'email est donc traité comme un moyen de comunication privilégié.
Mais sinon il me semblait que sur Gitlab et Gitea on pouvait référencer un dépôt externe lors de l'ouverture d'une demande de fusion. Ça aurait changé ? été désactivé depuis ?
[^] # Re: Besoin d'interopérabilité
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 05 mai 2025 à 15:56.
Tu peux proposer le patch par email aussi avec git format-patch et git send-email.
Ça ne te demande aucun compte.
[^] # Re: Besoin d'interopérabilité
Posté par wilk . Évalué à 7 (+5/-0).
On oublie souvent que git est déjà décentralisé.
On peut aussi créer sa branche sur une autre forge, le mainteneur n'a pas à créer de compte pour faire un pull sur une autre forge publique.
[^] # Re: Besoin d'interopérabilité
Posté par flagos . Évalué à 3 (+1/-0).
Une autre difficulté c'est aussi le CI. C'est bien de pouvoir faire une merge-pull request a partir d'une autre forge, mais si le CI ne peut pas tourner, c'est franchement dommage.
[^] # Re: Besoin d'interopérabilité
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Tu n'es pas obligé de merger dans la branche de developpement principale directement.
[^] # Re: Besoin d'interopérabilité
Posté par Computer (site web personnel) . Évalué à 0 (+0/-0). Dernière modification le 06 mai 2025 à 15:20.
Et le CI s'appuie sur les hooks¹. Pourquoi ne pas les utiliser ? Pourquoi ne pas se créer un système de tickets par fichiers directement dans le dépôt git du projet ? Pourquoi ne pas accepter des patchs² simplement envoyés par mail ? Bref pourquoi s'emprisonner volontairement avec un outil ou un service d'hébergement qui ne garantit pas l'indépendance et l'autonomie ? Du plus les forges forcent souvent le partage de l'historique du développement, or la décentralisation de git est bien plus poussée : chaque contributeur gère son historique comme il l'entend et n'est pas tenu de le partager : cela peut être critique en terme de performances sur de très gros projets. Les forges sont plus le fait de la programmation en entreprise où le travail est uniformisé, normé et segmenté. Le libre perd son âme à trop vouloir singer le monde professionnel, qui est aussi très souvent la réduction au plus petit commun dénominateur : un code et des outils de piètre qualité qui ont pour seul mérite une prise en main rapide, pour ne pas subir le turnover, et pour s'assurer qu'un collègue pas très compétent sera capable de comprendre et maintenir les sources.
¹ https://git-scm.com/docs/githooks
² https://git-scm.com/docs/git-format-patch
[^] # Re: Besoin d'interopérabilité
Posté par Pol' uX (site web personnel) . Évalué à 0 (+1/-3).
Question (ironique mais avec un soupçon de curiosité) : tu ne peux pas mandater une IA pour faire ça pour toi ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Besoin d'interopérabilité
Posté par Lutin . Évalué à 2 (+0/-0).
OpenID pourrait répondre à au moins une partie du problème.
[^] # Re: Besoin d'interopérabilité
Posté par ff9097 . Évalué à 3 (+1/-0).
Peut-être simplement du SSO ?
# fédération
Posté par leyouki (site web personnel, Mastodon) . Évalué à 3 (+3/-0).
Bonjour,
Chouette rebond sur une actualité :-)
La question de (dé-)centralisation me paraît être celle posée du côté du pouvoir. Si le lieu de prise de décision ou le lieu de dépôt collaboratif de code en l’occurrence est petit et bien délimité, ce lieu et ce qui s'y fait sera plus facile à contrôler.
Si l'on sort du point de vue de puissance et de contrôle et adopte le point de vue de la masse, la fédération me paraît être une gouvernance bien meilleure pour gérer ces biens communs et éviter l'accaparement par quelques-un·es.
# Un problème à la fois
Posté par gUI (Mastodon) . Évalué à 10 (+12/-0). Dernière modification le 05 mai 2025 à 12:38.
Je pense que la forge publique d'état, c'est déjà résoudre un soucis : proposer une alternative à GitHub (en gros).
Ensuite tout le monde sera d'accord pour dire que une fédération c'est mieux, mais c'est facile à dire, beaucoup plus dur à faire (ça ne se décide pas).
Donc oui, un service d'état (on pourrait même en proposer un Européen) c'est une première étape à encourager.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Un problème à la fois
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0).
Une forge publique d'Etat, ça demande un énorme et gigantesque appel d'offre commun à tout le secteur public avec des administrations/entreprises/associations/communes/… plus ou moins indépendantes avec des gouvernances variés et des besoins différents (du code secret défense à la gestion des salles des fêtes…).
Pas sûr qu'on y arrive plus vite et pour moins cher qu'en montant des petites forges :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un problème à la fois
Posté par ckiller . Évalué à 4 (+3/-1).
et puis une forge publique, c'est aussi perdre de la liberté. Car ils n’hésiteront pas à virer les projets qui les ennuient, genre libdvdcss, et avec beaucoup plus de virulence que les monopoles américains.
Perso, je n'ai pas confiance.
Donc, oui à la décentralisation, non à la forge étatiste.
[^] # Re: Un problème à la fois
Posté par gUI (Mastodon) . Évalué à 10 (+7/-0). Dernière modification le 05 mai 2025 à 21:59.
Ça c'est ton avis, pas le mien.
Je pense qu'une forge publique se doit de respecter la loi, tout comme une forge privée, mais si tu as des exemples d'abus à dénoncer, je suis tout ouïe.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Un problème à la fois
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 8 (+6/-0).
"ça demande un énorme et gigantesque appel d'offre commun à tout le secteur public "
Là, je reconnais le pattern "Il faut sauver le soldat Atos".
…
hurlements lointains et gargouillis de vomi.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Mutualisation inter-ministérielle
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 9 (+8/-0).
Pour le secteur publique il y a déjà https://gitlab.mim-libre.fr/ qui est utilisable.
[^] # Re: Mutualisation inter-ministérielle
Posté par hugotrip . Évalué à 4 (+3/-0). Dernière modification le 06 mai 2025 à 09:11.
Et pour prolonger, dans l'éducation nationale, il y a aussi une forge, qui tourne aussi avec gitlab :
https://forge.apps.education.fr/explore/projects/starred
Il semble d'ailleurs que la mutualisation soit plus poussée entre les ministères car par exemple, les pages d'accueil/connexion des deux sites est très similaire :
- https://portail.mim-libre.fr/signin
- https://portail.apps.education.fr/signin
[^] # Re: Mutualisation inter-ministérielle
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3 (+2/-0).
C'est logique, les deux portails sont basés sur https://gitlab.mim-libre.fr/alphabet/laboite
Voir ce billet de blog https://blog.mim-libre.fr/articles/migration-du-portail-mim-libre2024-03-21t030822411z
# Centralisons presque tout
Posté par el_profesor . Évalué à 1 (+1/-0).
Hello,
Pour répondre simplement à ta question, personnellement, je suis plutôt centralisateur. J'ai travaillé dans plusieurs grosses boites qui centralise tout. Je trouve ça smart pour la gestion de la forge logiciel, les upgrades, les accompagnements d'équipes et surtout les déploiements.
Bien sur dans tout cas il faut savoir gérer finement les droits et avoir une bonne organisation.
[^] # Re: Centralisons presque tout
Posté par steph1978 . Évalué à 2 (+0/-0).
Dans les faits, c'est déjà le cas pour les repo de packages : pypi pour python, npmjs pour JS, crates.io pour Rust, cpan pour perl, etc. Et pour ceux qui ne l'on pas (C), c'est pas pratique.
Pour les forges, je ne sais pas si la centralisation apporte beaucoup. Pour la coopération (issues, pr) peut être ; mais cela sera peut être réglé par la fédération.
# Quelle pérennité ?
Posté par lolop (site web personnel) . Évalué à 6 (+4/-0).
J'ai une crainte avec de petites forges disséminées, c'est que des projets disparaissent faute de moyens de les soutenir…
Une seule grosse forge, c'est trop centralisateur, donc plutôt plusieurs, éventuellement par grands usages. Et si ça pouvait être fédéré, oui (voir, authentification possible – pas obligatoire) avec des outils externes gafam…
Et si ça pouvait être des services de l'État (pas des sous-traitants, des gens impliqués pour la communauté) – on peut toujours rêver d'un état réellement souverain.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Quelle pérennité ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
Pour ne pas disparaître, un projet doit pouvoir changer de forge.
Pour mes projets persos, je suis passé par de l'autohébergement, par chiselapp, Tux Family, github, gitlab et maintenant codeberg.
Tant qu'il y a un dev, le projet ne peut pas mou
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.