Quitter Github, un mode d'emploi?

Hello,

Pour l’association YesWiki, on discute en ce moment de comment quitter Github comme dépot de code, avec quelle stratégie (assurer une sync (et comment l’assurer), tout effacer chez github, aller chez un chaton, un hébergeur associatif, s’autohéberger, sur quelle forge logicielle, etc…).

Bref de multiples possibilités, et donc je me demandais si vous aviez traité ce sujet dans vos chatons, documenté le process, le cas échéant ca serait peut être intéressant de mutualiser voire de faire des guides chatons sur comment sortir des gafam : le cas github (et autres).

Si vous avez des pistes, ca serait super!

Merci d’avance!

Amitiés

Florian aka mrflos

6 Likes

Chez ARN on utilise la forge code.ffdn.org malheureusement c’est difficile d’inscrire des personnes car il faut demander à l’équipe d’adminsys de la FFDN du coup ça ralentit la contrib je trouve…

Côté ynh, on attend la fédération annoncée pour 2023 dans plusieurs projets.

1 Like

Je n’ai pas connaissance d’un mode d’emploi… ce serait bien que Hostea travaille dessus. L’objectif de https://forgefriends.org est de résoudre ce problème en fédérant les forges logicielles (qu’elles le veuille ou non), mais l’objectif n’est pas encore atteint, ça va prendre un peu de temps :sweat_smile:

Si la discussion pour YesWiki est publique, j’y contribuerais volontiers. La bonne solution dépend de pas mal de détails et ça commence par une question: est-ce qu’il y a les moyens humains et financiers de faire tourner et maintenir une forge dédiée?

J’utilise Fossil, qui est une forge et un DVCS décentralisé créé par les gens de SQLite, qui utilise SQLite. y’a des tickets, un forum, un chat, un wiki, un générateur de diagrammes, la gestion des comptes utilisateurs, bref ça fait un peu tout et c’est léger et contenu. C’est pas fédéré par contre. Mais contrairement aux autres forges, toutes les données de la forge sont décentralisées (tickets, wiki, forum, etc.) : quand tu clone le repository tu as tout sur ton ordi, et tu peux ensuite travailler hors ligne dessus, il y a un serveur web avec une interface, tout inclus. Si tu perds le repo principal, tu peux remonter un repo complet avec ta copie locale, les données seront les même. L’interface est pas mal, on peut naviguer dans l’historique très facilement. Perso je trouve Git très loin en terme d’UX et fonctionnalités :slight_smile:

Par contre si on aime git, on peut ne pas aimer la philosophie de Fossil : on ne peut pas réécrire l’historique (pas de rebase, pas de force push), et généralement l’option autosync est activée (= chaque commit est poussé automatiquement au repo principal). C’est plus fait pour travailler en petite équipe. C’est simple à utiliser comme SVN, mais beaucoup plus puissant et pratique.

C’est un seul binaire à installer sur le serveur, et ensuite 2 lignes dans la conf apache pour renvoyer les requêtes vers le binaire en mode CGI, donc aussi très facile à installer. Fossil intègre un import/export Git donc on peut avoir le repo github synchronisé avec le Fossil.

2 Likes

Chez Pâquerette, nous avons une instance Gitlab que nous souhaitons mutualiser. On peut héberger des CHATONS pour partager les frais du serveur.

1 Like

Merci pour toutes vos réponses!

@ljf : la fédération de forges promet en effet de belles choses, vivement 2023! Mais il nous faudra migrer ailleurs quand même, et on se pose la question de faut-il garder les repo sur Github ou partir totalement, voire laisser une archive et indiquer le nouveau dépôt principal. La fédération permettrait sans doute de synchroniser avec Github, mais on a t’on vraiment envie de continuer à garder ce lien?

@dachary : nos discussions ont lieu sur la canal Développement du framateam de YesWiki, donc ce n’est pas tout à fait public mais ouvert aux personnes avec un compte chez framateam. Ceci dit, j’ai partagé le lien vers cette discussion du forum et autant continuer par ici publiquement ?
Pour les parties moyens, comme toute les petites associations, c’est tres limité : l’asso provisionne un budget d’environ 1000 euros par an pour de la location de serveur et des backups, qu’on utilise pour héberger les sites et services autour de yeswiki (peut etre un futur chaton? :wink: ), avec une machine sous yunohost.
Les moyens humains sont bénévoles, et quand un chantier n’avance pas et/ou ne trouve pas de bénévoles, l’association peut décider d’attribuer un budget de prestation.

@bohwaz merci du partage sur Fossil, j’avais vu mentionné, mais jamais pratiqué, c’est une super feature le fait que les issues tickets et autres soient aussi décentralisés! Par contre à voir si cela ne fait pas trop de nouveaux trucs à apprendre, faut dire que git, même en étant inférieur à d’autres technos à un peu pris le lead sur les solutions de code versionning…

@dhebert super, merci de la proposition! C’est une bonne idée de mutualiser, après c’est toujours compliqué entre l’envie d’être totalement autonome, ou dans le cas d’une mutualisation comment gérer la gouvernance, les accès etc, on nous a suggérer de mutualiser avec Globenet aussi, mais compliqué de choisir du coup! J’aime bien l’idée aussi d’aller chez des chatons « spécialistes » comme hostea, mais ca pose toujours cette question de veut on la totale autonomie ou un bon rapport cohérence/temps à y passer/soustraitance-dépendance, pas facile à trancher!

Au dela du choix d’où aller, il y a pour moi aussi la question de qu’est ce qu’on perd (par exemple la visibilité sur github), et surtout quels sont les solutions faciles à maintenir et qui ont des options de migration un peu clé en main, voila ou j’en suis en regardant d’encore un peu trop loin :

  • gitlab à l’air d’avoir des importateurs depuis github bien foutus, mais importe t’il vraiment tout ? issues, wiki, organisations avec de multiples dépots, etc. meme gitea semble galèrer à quitter github cf. https://mastodon.cc/web/@gitea@social.gitea.io/108833229480663153
  • gitea semble facile à maintenir avec l’aspect binaire de Go, mais je n’ai pas testé, et ensuite sur les imports ou fonctions avancées comme la CI, je ne sais pas trop
  • fossil, je ne connaissais pas, mais là faut tout ré-apprendre, et niveau importation, pas d’idée

Bref, compliqué!

Vu qu’il y a déjà des services auto-hébergés et du matériel, je recommande:

  • Installer un GitLab
  • Prévoir un maximum de 4h par trimestre pour les mises à jour (c’est moins que ça mais un jour ça va bugger pour une raison ou une autre et ça va consommer du temps)
  • Migrer les projets avec l’import (c’est pas parfait mais ça aide)
  • Garder les projets sur GitHub en lecture seule

Il y aura une période d’inconfort de quelques semaines au plus: être à cheval sur deux plateformes, aller chercher ce qui a été oublié etc. Mais ça ne fait que s’améliorer avec le temps. Je n’ai pas idée de l’envergure de ce qui est à migrer mais je serais très surpris que GitHub soit plus qu’un souvenir dans un an. Et dans deux ans ça pourra probablement être effacé.

Mes 2cts

P.S. La visibilité sur GitHub est un mythe (intéressant a quel point il est répandu)

2 Likes

La discussion est super intéressante, je suis avec intéret, merci ! Je voudrais juste nuancer un tout petit point et partager un peu d’expérience à ce sujet :

Je ne sais pas si c’est un mythe ou pas, j’ai pas d’avis sur le sujet à part que, dans le libre on a tendance à s’auto invisibiliser. Notre expérience perso :

Le miroring automatique Gitea => Github + création de compte a pris en tout et pour tout : 30 minutes. Le coût est donc pas énorme, c’est une fonctionnalité de Gitea qui est super facile à setup.

L’idée c’est pas de faire dériver la discussion sur la question du sens des stars, ni le biais que Github introduit (les gens ont déjà un compte sur Github mais pas notre forge, etc.), bref c’est pas scientifique comme exemple. Mais j’ai la conviction que des gens ont entendu parler de nous via Github, et plus particulièrement via leur timeline Github - j’ai des données qualitatives sur la question en regard des données quantitatives sur les stars -, et clairement si on a une approche FOSS first, on va pas se priver d’un peu d’exposition sur les outils privateurs par pureté militante ^^

4 Likes

Le problème avec Gitea ce n’est pas let setup initial, c’est les mises à jour et les régressions. J’en suis content et je développe dessus tous les jours mais l’investissement en temps pour éviter de tomber sur des problèmes est nettement plus important que pour GitLab (cf le guide d’upgrade).

2 Likes

Pour ce qui est de YunoHost, on ne souhaite pas spécialement la fédération pour être sur github… C’est plutôt qu’on souhaite qu’une personne sans compte sur notre futur forge git, puissent suivre le repo, faire des pull request, des tickets, etc. EN fait, on espère un départ massif des libristes à ce moment précis.

3 Likes

Bonjour,

Mon associé à attiré mon attention sur cette discution, je me suis inscrit pour l’occasion car jusqu’à présent je suivais les discutions en invité.

Nous pensons en effet qu’il est largement temps d’abandonner Github, et nous ne somme pas les seuls à le penser.

À titre personnel je pense même qu’il est temps d’abandonner tous les hébergeurs US, j’en parlais déjà il y a 2 ans et demis dans un de mes podcasts. C’est même cette prise de conscience qui m’a fait créer Froggit, pour offrir une alternative centralisé aux professionnels.

Au niveau des forges il y a, encore assez peu de choix avec une centralisation.
La centralisation, même si elle à des inconvénients, à beaucoup d’avantages :

  • moins de coût énergétiques car il y a mutualisation des ressources
  • facilité de coopération avec une seule plateforme
  • facilité de navigation et de liens entre les projets d’une même instance

Pour le moment j’ai identifié en forges centralisées en France :

Si on étend à l’Europe :

Si vous en avez d’autre je suis preneur pour alimenter ma liste d’alternatives.

Ce serait vraiment génial et ça permettrai d’avoir un compte unique et de ne pas en créer un sur chaque plateforme. Je sais que GitLab étudie le sujet depuis des années.

Concernant la migration vers GitLab j’ai fais quelques vidéos sur le sujet.

Dans un premier temps je conseil de migrer le dépôt sur GitLab puis de mettre en place un miroir vert Github en cas de besoin. C’est ce que nous avons fait pour notre collection Ansible qui permet de gérer YunoHost. Nous Travaillons sur Froggit avec un miroir sur Github.

GitLab importe pas mal de données mais uniquement sur les projets.

1 Like

J’utilise gitea et woodpecker pour ma forge perso, et j’ai relativement peu de souci avec Gitea pour mon usage (eg des roles ansibles, des sites webs privés avec déploiement via la CI). J’ai automatisé la mise à jour via un script qui va directement voir sur github, chope le tarball, vérifie la somme de controle, etc et installe lance tout (et aussi un role ansible pour déployer tout). J’ai commencé avec la version 1.14.1 et j’ai eu 1 fois un souci à cause de l’upgrade. Ça a été corrigé assez vite, et le workaround n’était pas vraiment trop compliqué à mettre en oeuvre ou à déboguer (mais bon, c’est aussi mon quotidien ).

Le souci de Gitlab et Gitea, c’est à mon avis pas la forge ou son update, mais la gestion du spam qui devient vite une tache chronophage quand la forge est publique et que le projet a du succès, surtout si tu as une CI à coté, et ça ne va aller qu’en augmentant avec la fédération.

Et dans le cas de Gitlab, tu te retrouves assez vite à avoir besoin de features proprios pour éviter les abus comme Gnome l’a découvert y a 4 jours (une raison de plus de ne pas recommander un truc en open core).

Le cas de gnome est que des spammeurs proposent des patchs qui vont faire tourner des cryptominers sur la CI de Gnome, ce genre de choses. Mais j’ai aussi vu les spammeurs qui ouvrent des comptes juste pour ajouter des liens ou des pubs, etc. Et aussi les gens qui vont juste ouvrir des comptes et se servir de la forge comme stockage de données.

Je n’ai pas le souci parce j’ai une forge privé, mais si la forge propose une CI, il faut aussi faire attention à ce qui tourne dessus, à avoir des environnements jetables (ou facilement réinstallable à minima), à bien séparer les builds, etc. C’est un avantage de Github et sa CI intégré qui tourne sur Azure.

Et si tu veux avoir le même niveau de tranquillité chez toi, il faut quasiment installer ton propre cloud privé en installant Openstack, une tache que Dante Alighieri aurait décrit dans la Divine Comédie si le livre avait été sur l’informatique moderne. Et même la, tu n’es pas à l’abri d’une théorique attaque sur le hardware (j’insiste très fortement sur le « théorique », je mentionne par complétude, mais je doute que ça arrive).

L’autre solution, c’est de passer par un fournisseur Openstack tierce, mais je sais pas à quel point c’est compatible avec la charte CHATONS.

La 3eme solution, c’est de ne lancer la CI que si un membre du projet donne le feu vert, ou ce genre de choses. C’est un peu chiant à faire et ça rajoute de la friction (et la friction dans un projet libre, c’est mal™ cf la littérature existante sur le sujet, comme The art of Community), mais ça se fait.

Et pour woodpecker, ça marche bien, même si il manque encore quelque fonctions pour que je bouge les derniers workflows hors de github (taches périodiques, intégration avec gitea pour avoir un token éphémère et pousser des paquets).

1 Like

Bonjour Florian,
Quelle solution avez-vous finalement choisie ?

Bonjour @Charlotte_dAlsace , nous n’avons pas encore choisi, cela passe par une décision collective des développeurs et on n’a pas encore eu de réunion pour s’en parler.
J’ai testé avec succès l’import de Github vers Gitlab, mais personnellement, bien qu’il soit moins élaboré, j’aimerais aussi tester gitea, qui me semble plus facile à maintenir car moins gros, et qui semble avancer plus vite sur le sujet de la fédération des forges.

On est encore aux décisions et tests, je partagerai les évolutions sur ce fil.

@mrflos Si tu choisis Gitlab en Mutualisé, on peut vous créer un espace et un compte gestionnaire de test sachant que nous avons déjà un client qui héberge sa forge chez nous.
Pour l’instant, nous n’avons pas encore regardé le côté mutualisation mais @frju365 m’en avait déjà parlé.
Je pense que le point le plus important concerne le sujet de la gouvernance sachant que nous sommes très souple et ouvert à toute collaboration.
Dominique

1 Like

Il existe par exemple l’association Codeberg. Il est possible d’y avoir un compte gratuit ou de faire un don et de soutenir l’association en devenant membre. Codeberg utilise Gitea et est à l’origine de logiciels open source.

Gitea est un bel outil qui a la meilleure fonctionnalité de recherche. Mais les fonctionnalités de sauvegarde et de restauration sont très basiques. Par exemple, il n’y a pas de fonction de sauvegarde automatique, il est difficile de restaurer une sauvegarde. De plus, la routine d’installation initiale basée sur le Web de Gitea permet de sélectionner les fonctionnalités et les options que vous souhaitez activer ou désactiver dans la configuration. Après cela, un seul fichier de configuration gère tous ces ajustements et options.