Gitea: Gitea a hébergé Gitea

Très bonne idée!

1,2 en février, 1,3 en avril, 1,4 en juin, 1,5 en août ? devrait être assez de temps pour mettre en œuvre tout cela 😄

Si vous ne l'avez pas vu, commentaire fantastique et perspicace soutenant votre approche de l'auto-hébergement uniquement lorsque vous êtes prêt : https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny Maintenant que j'y pense (merci @zellyn pour ce lien 😂 ) Pourquoi avons-nous besoin d'un fournisseur d'oauth, d'un support de webhook _complete_, d'une documentation api et d'une API _complete_ pour l'auto-hébergement ?

OAuth _Consumer_ est requis (il est fusionné AFAIK) pour que les gens puissent se connecter à l'aide de github auth.
Le drone n'utilise que des crochets de poussée, alors pourquoi aurions-nous besoin de l'autre ?

En ce qui concerne l'API, je ne sais pas pourquoi l'auto-hébergement nécessite cela du tout TBH :)

Je suis d'accord pour couper cette liste. Un auto-hébergement plus précoce nous aidera très probablement à mieux définir les priorités :)

@bkcsoft peut-être pouvons-nous configurer un site hébergé et essayer.

@bkcsoft J'ai mis à jour le problème, vous voulez dire ça ?

-> Le fournisseur OAuth (#27) n'est pas fermé

@ekozan pas fermé, mais rayé de la liste des "choses dont nous avons besoin"

Ajout de "Limites de taille de référentiel" car nous n'avons pas de stockage illimité sur les serveurs...

Ma proposition de limites :

• 0 organisations
• 3 dépôts
• 1 Go/dépôt

@bkcsoft Voulez- vous dire que ce sera un service public pour n'importe qui ?

Peut-être, peut-être pas, mais _si_ ça devient un service public on ne peut pas l'avoir en illimité ;)

Je pense que le dogfooding est suffisamment important pour que les limites de taille des dépôts n'aient pas besoin d'être dans le chemin critique pour l'auto-hébergement de gitea. Au cours des premiers jours après la migration vers gitea, j'ai rencontré plusieurs omissions de fonctionnalités qui m'ont fait penser que l'auto-hébergement aidera à concentrer les efforts sur la réalisation de ces choses. Gitea est déjà un outil fantastique, très utilisable et performant - c'est vraiment dommage que vous ne l'utilisiez pas vous-mêmes. ;-)

Plutôt que de dépendre de limites de taille strictes, il peut être utile de réfléchir à la façon dont le serveur auto-hébergé va être administré, qui va contrôler les mauvais comportements et quels outils ils voudront. Par exemple, les forks des contributeurs du projet gitea devraient être supportés sur le propre serveur de gitea. Cela expose le risque qu'un utilisateur fork gitea, puis pousse warez vers sa fourchette. Les limites de taille peuvent aider à empêcher la diffusion de fichiers binaires volumineux, mais peuvent ne pas aider avec une liste de mots de passe ou de numéros de carte de crédit. Un outil qui pourrait aider dans ce cas est quelque chose qui détecte les fichiers étrangers par le nombre de lignes diff ou le hachage roulant.

Un bon effet secondaire de la disponibilité d'un outil de taille de différence est que le code pourrait être disponible en tant qu'option à exécuter pendant les poussées pour signaler les commits légitimes qui auraient de toute façon dû être divisés en plus petits morceaux. (Discussion connexe pour savoir comment procéder : https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

Je parie qu'il y a beaucoup d'autres choses subtiles qui devront être résolues pour les serveurs publics. Il peut être judicieux d'utiliser un problème principal ou un jalon « d'hébergement public » distinct pour suivre ces éléments.

En parlant de jalons, ce problème devrait-il être ajouté à la 1.5.0 ?

@stevegt Non, car je pense que tous les PR ne seront pas fusionnés / résolus à 1.5.0.

J'ai supprimé Repository Size Limits (#3658) du problème car cela n'affectera pas Gitea hébergé gitea.

J'ai supprimé les limites de taille du référentiel (#3658) du problème car cela n'affectera pas gitea hébergé par Gitea.

Super! Je suis convaincu que plus tôt Gitea s'héberge, plus vite l'ensemble du projet profitera d'expériences réelles, et gagnera en confiance :)

@lafriks mentionne dans un autre fil :

L'auto-hébergement nécessiterait probablement un financement/un parrainage supplémentaire pour payer une machine virtuelle supplémentaire

Et @lunny demande ci-dessus :

@bkcsoft Voulez- vous dire que ce sera un service public pour n'importe qui ?

Serait-il possible de combiner ces réflexions dans un "Que diriez-vous de mettre en place un service Gitea en ligne, où les gens paient pour (disons) des dépôts privés ?".

Si c'est bien fait, cela devrait générer les fonds pour se payer + les repos publics.

En tant que concept, il semble être un terrain assez bien parcouru. :le sourire:

À ajouter rapidement à l'idée de @justinclift ; le moment est peut-être venu avec les nouvelles actuelles de Microsoft prenant le contrôle de GitHub.

@lafriks mentionne dans un autre fil :

L'auto-hébergement nécessiterait probablement un financement/un parrainage supplémentaire pour payer une machine virtuelle supplémentaire

Je suis convaincu qu'il y aura des financements de la communauté ou du parrainage d'organisations pour rendre possible l'hébergement de gitea. Étant donné que Gitea est respectueux des ressources (oui, GitLab, je vous regarde), ce ne sera pas un gros problème.

@mxmehl jusqu'à présent, 5 personnes ont contribué depuis l'ouverture de l'opencollective le mois dernier : https://opencollective.com/gitea

@justinclift car Gitea est purement communautaire, il n'y a aucun moyen de mettre en place des référentiels privés payants car cela nécessite de créer une entreprise, de gérer les impôts et d'avoir du personnel à temps plein pour faire face aux problèmes techniques

@mxmehl jusqu'à présent, 5 personnes ont contribué depuis l'ouverture de l'opencollective le mois dernier : https://opencollective.com/gitea

@techknowlogick Je ne connaissais pas cette page. Maintenant c'est 6 ;)

@lafriks Eh bien... il y a des projets communautaires autour - pour les logiciels et non-logiciels - qui semblent se gérer eux-mêmes correctement, y compris les questions financières, les choses qu'ils paient, le personnel (si nécessaire), etc.

Cela étant dit, cela nécessite un niveau de volonté pour y arriver + le maintenir. Les personnes occupant tous les rôles nécessaires doivent également être de bons gardiens (dignes de confiance, fiables, informés).

S'il n'y a pas d'intérêt, alors ça n'ira nulle part de toute façon. Idem si aucun type de « dépositaire » approprié ne peut être convenu.

D'après le lien Open Collective mentionné ci-dessus, il semble que certaines graines initiales soient en place. Cela montre qu'il y a des gens autour qui sont considérés comme des gardiens. :le sourire:

@justinclift Je ne dis pas que ce n'est pas possible, mais pas au stade actuel, mais à l'avenir, cela pourrait arriver. Actuellement, au moins, je ferais mieux de me concentrer sur le développement de nouvelles fonctionnalités Gitea et l'amélioration de la documentation :) Donc, toute aide est très appréciée pour avancer plus rapidement vers cet objectif.

Hé hé hé

Pas de soucis du tout @lafriks. :le sourire:

Le premier objectif est que Gitea héberge Gitea depuis que github s'est marié avec Microsoft. :)

Je pense que seuls les #2519 et #3748 ont besoin d'être révisés et fusionnés avant de clore ce problème.

@bkcsoft

Ajout de "Limites de taille de référentiel" car nous n'avons pas de stockage illimité sur les serveurs...

Ma proposition de limites :

• 0 organisations
• 3 dépôts
• 1 Go/dépôt

Je pense qu'avec la limite de quantité de dépôts, nous pouvons ajouter permet de définir pour fork uniquement les dépôts existants pour tous les utilisateurs ne faisant pas partie de l'équipe Gitea :

• 0 organisations
• 3 Repos (autoriser uniquement les fourches)
• 1 Go/dépôt

Je ne pense pas que le nombre de fork doive être limité, il serait de toute façon limité par le nombre de référentiels gitea org, donc ça devrait aller.
Quant à la taille du dépôt, oui, il devrait probablement y avoir des limites

Nous devrions limiter la création d'organisations, la création de dépôts, donc la limite de taille des dépôts n'est pas un problème nécessaire pour Gitea hébergé par Gitea.

Nous pourrions envisager d'ajouter #3134 et #4302 (RP et problèmes de backlinks) à la liste des prérequis pour l'auto-hébergement - je suis peut-être unique, mais notre propre petite installation de gitea a commencé à devenir lourde sans ces backlinks dès que nous avons ajouté plus de quelques utilisateurs et problèmes. Nous avons pu contourner ce problème avec la recherche de problèmes, mais cela est limité sans la recherche de problèmes globale (#2434/#3841).

@stevegt Bien que les backlinks soient bien, je ne les vois pas bloquer le passage à l'auto-hébergement :)

@bkcsoft Assez juste - je pensais juste que je le mentionnerais au cas où cela déclencherait des réalisations. Dans notre cas local, nous avons pris l'habitude d'ajouter manuellement les backlinks dans les commentaires de problème comme solution de contournement.

J'ai récemment entendu parler de l'effort de https://teahub.io. Ils veulent créer une organisation à but non lucratif. Gitea ne peut-il pas l'utiliser une fois qu'ils sont prêts avec la configuration ?

@jlelse Non. Gitea mettra en place un serveur autonome (c'est-à-dire self.gitea.io) pour héberger gitea et mettre en miroir sur github, gitlab ou teahub, etc.

@lunny Avons-nous vraiment besoin de commentaires sur les commits puisque nous n'utilisons actuellement que des commentaires sur les relations publiques sur GitHub ?

@JonasFranzDEV Je veux dire les commentaires sur les commits de PR, je pense que c'est nécessaire.

Je commente ici car le #4108 est fermé. Lorsque le Gitea Patreon (ou une alternative semblable à Patreon) monte, j'ai besoin de le savoir. Je vais contribuer. J'aimerais voir ce projet auto-hébergé et développé davantage. Une fois que j'aurai déplacé tous mes référentiels, je ne dépenserai plus d'argent avec Github, je l'engagerai mensuellement dans Patreon.

@ryanburnette https://opencollective.com/gitea

@lunny ressemble à « Système d'approbation » dans le début du sujet peut être barré. (Les issues étant respectivement fermées et fusionnées) ?

@mjmlvp je pense que tu as raison. J'ai supprimé #996 #2519 car cela ne devrait pas être un bloc de ce problème. Nous allons mettre en place un serveur pour héberger nos développements.

Des nouvelles à ce sujet ?

Oui, nous devons toujours ajouter des limitations d'approbation, puis nous pouvons migrer vers le code auto-hébergé

Ce serait bien d'ajouter les problèmes ouverts pour cela à la liste. Pour le moment, il semble que tous les problèmes et PR liés aient été fermés et fusionnés.

@skddc terminé.

pour l'enregistrement

serveurs gitea ouverts

• https://try.gitea.io/
• https://teahub.io/
• https://dev.sum7.eu/

ne fais confiance a personne. faire des sauvegardes régulières

@giteauser je ne vois pas en quoi c'est pertinent

@giteauser et il s'agit du développement auto-hébergé de gitea, afin que le développement de gitea n'ait plus à se produire sur github. Je ne vois toujours pas en quoi cela est pertinent.

Oh, je les ai postés pour le mauvais problème, je suis désolé.

Ainsi, toutes les fonctionnalités nécessaires devraient être implémentées maintenant. Pouvons-nous avoir une nouvelle version et migrer ?

Bon, nous allons configurer une instance gitea pour héberger le développement de gitea.

Je pense que la résolution du problème du vidage de sauvegarde et l' ajout d'une fonctionnalité de restauration appropriée sont également un élément important de la gestion de l'infrastructure d'un gitea auto-hébergé

Si vous déployez Gitea sur Kubernetes, je peux recommander Ark pour les sauvegardes et les restaurations.

D'une manière générale, la sauvegarde ne semble pas devoir être un sujet bloquant pour le développement de Gitea en auto-hébergement, car chacun a généralement des stratégies/programmes de sauvegarde différents, en fonction de son choix de plate-forme, de méthode de déploiement, d'outils existants, etc. ne devrait être un problème bloquant que pour la préparation à la production de cette instance.

@max-wittig Le site Web auto-hébergé de gitea fonctionnera sur un fournisseur de cloud public. Ils fourniront un service RDS et un outil de sauvegarde de base de données et une fonction de sauvegarde de disque afin que la commande de vidage de sauvegarde ne soit pas un problème de dépendance. La commande dump est destinée à un service gitea à nœud unique. Bien sûr, nous devrions résoudre ces problèmes.

@skddc C'est un outil intéressant que nous pouvons considérer cela.

J'espère vraiment que la version 1.8.0 sera la version où gitea deviendra auto-hébergé. Personnellement, j'aimerais l'utiliser pour mes propres projets, mais je n'utilise gitea que comme miroir pour la simple raison que je ne lui fais pas assez confiance si les développeurs - vous les gars - ne l'utilisent même pas pour le développement de gitea. De plus, j'aimerais proposer d'utiliser gitea dans mon environnement de travail, mais je ne peux même pas le proposer, car je me moquerai de moi quand je dirai: "oh btw, ça a l'air génial, mais les développeurs de gitea n'utilisent pas pour leur propre projet" ...

Il ne s'agit pas d'une critique ou d'un moyen de vous pousser. Je vous fais juste savoir ce que je (et probablement beaucoup d'autres) trouverais gênant lorsqu'il s'agirait d'utiliser gitea comme système de contrôle de code source principal ;)

Enfin, pour être un peu plus constructif. Si vous cherchez un très bon (et pas cher) clouds vps pour les sauvegardes ou même pour héberger gitea on, jetez un œil à hetzner https://www.hetzner.com/storage/storage-box Bien que pour une infrastructure importante comme Gitea vous voudriez probablement le sauvegarder à deux endroits complètement différents (par exemple, hetzner et digitalocean).

@markg85 nous travaillons sur https://gitea.com

Une mise à jour sur gitea hébergé gitea sur gitea.com ?

@zachdoty travaille toujours là-dessus.

J'ai oublié quelque chose de nécessaire pour passer de github à gitea. Nous devons déplacer toutes les données (y compris les données git, les problèmes, les commentaires, les demandes d'extraction de github vers gitea), mais en fait, je n'ai pas trouvé d'outils appropriés pour le faire. J'ai envoyé un PR concernant le déplacement du référentiel de migration du frontend vers le backend, voir #6200 , et https://gitea.com/gitea/migrator devrait également être fusionné avec gitea car l'API de gitea ne permettra pas de créer un problème avec le numéro d'index spécifié.

gitea-github-migrator peut migrer presque tout, au cas où vous ne l'auriez pas encore trouvé. S'il manque quelque chose, il peut peut-être y être ajouté, afin que d'autres projets disposent également d'un bon outil de migration.

@skddc, ce sont en fait les mêmes.

Ah désolé. Je n'avais pas suivi le lien.

Comme @kolaente l'a dit, nous avons invité @jonasfranz à déplacer gitea-github-migrator vers gitea.com et j'envoie un PR https://gitea.com/gitea/migrator/pulls/1 veut améliorer cela. Mais j'ai trouvé qu'en tant qu'outil tiers, il y a un inconvénient. C'est qu'il est difficile de garder l'index des problèmes comme avant. (Pour laisser tous les liens sur le problème toujours disponibles.) Je pense donc que fusionner l'outil de migration dans gitea sur l'interface utilisateur de migration est une meilleure idée.

Ce serait vraiment génial si les liens internes dans les commentaires, etc. pouvaient être préservés. Ce serait également génial si les PR qui proviennent du même référentiel pouvaient être importés en tant que PR réels au lieu de problèmes !

J'ai ajouté une nouvelle tâche Migrate a throughout github repository to gitea sur le contenu du problème et je l'ai déplacée vers la 1.9.0 afin que cela ne bloque pas la sortie de la v1.8. Mais je ne pense pas qu'il faille attendre la sortie de la v1.9 puisque gitea.com suivra le maître.

La production de Gitea.com est-elle prête, par exemple dois-je m'inquiéter du stockage du code et de sa perte ?

@BNolet, nous avons mis en place un cluster ceph de 6 machines pour stocker les référentiels. Il ne faut donc pas le perdre facilement puisque toutes les données seront copiées 3 fois. Nous travaillons sur la configuration d'une autre sauvegarde via ceph mirror. Et puisque git est distribué. Vos codes seront toujours stockés sur votre disque ou celui de vos collègues.

Wow c'est fantastique ! Prévoyez-vous tous pouvoir être une alternative complète à GitHub ou Gitlab ?

Je ne pense pas. L'objectif principal de gitea.com est d'héberger lui-même les développements de gitea. Bien que nous n'ayons fait aucune limitation sur gitea.com, nous vous encourageons à configurer vous-même une instance Gitea hébergée car c'est si simple.

Une raison pour ne pas activer la connexion OpenID ?

@lunny j'en ai un et je l'adore :D

Quelle est la probabilité que CI/CD fasse partie du produit Gitea ?

@strk oublie ça. Activera la connexion OpenID.
@BNolet Gitea lui-même utilisera un drone comme CI/CD principal.

Obtention d'une erreur 500 lors de la tentative d'utilisation de l'option oauth Github sur la page de connexion, après avoir effectué la demande d'autorisations pour l'application go-gitea sur Github.

Dois-je attendre un peu pour découvrir l'instance phare ?

@jakimfett c'est un problème connu. Vous pouvez essayer deux fois et c'est OK.

@strk oublie ça. Activera la connexion OpenID.

@lunny car il était encore éteint aujourd'hui, y a-t-il peut-être un script de déploiement qui ne cesse de le désactiver ?

@jakimfett c'est un problème connu...

Jetez une modification avec le numéro de problème et je ferai le suivi là-bas.

_modification(s) : formatage_

Codeberg est un service gratuit basé sur Gitea. Peut-être que Gitea pourra y installer un miroir officiel. Actuellement, il est mis en miroir sur https://codeberg.org/Codeberg/gitea.

Gitea sera hébergé sur https://gitea.com/gitea/gitea , et nous avons déplacé la plupart des autres packages vers https://gitea.com/gitea , et gitea lui-même est en cours. Mirror est le bienvenu sur tout autre service basé sur Gitea.

@lunny a commenté hier :
Mirror est le bienvenu sur tout autre service basé sur Gitea.

Je vais bricoler un miroir à jour une fois que je serai rentré de mon week-end.

En rapport:
Y a-t-il une liste de miroirs quelque part, et est-ce que je m'y ajoute, ou... ?

@jakimfett Il n'y en a pas, mais vous pouvez créer un pr avec une nouvelle page de documentation

Pour un meilleur gestionnaire d'utilisateurs lors de la migration de gitea loin de github, j'aimerais déplacer cela vers la v1.10 et je pense que nous devrions implémenter https://github.com/go-gitea/gitea/issues/7293 avant de commencer la migration.

Je serais totalement pour ce déménagement s'il n'était pas hébergé en Chine ou si l'e-mail d'activation prenait 10 minutes pour arriver.

Je serais totalement pour ce déménagement s'il n'était pas hébergé en Chine ou si l'e-mail d'activation prenait 10 minutes pour arriver.

Edit : apparemment, je me suis trompé.

d'après certaines recherches sur Google, apparemment, l'adresse IP de gitea.com est en fait au Japon, pas en Chine. Cette adresse IP appartient cependant à Alibaba.

Nous utilisons mailgun.org pour envoyer des mails. Je ne sais pas pourquoi ça va durer 10 minutes.

Notre fournisseur de cloud de dons est didiyun qui est en Chine et il fournit de nombreuses machines. Nous n'avons pas d'autre choix actuellement.

Et le premier objectif de gitea.com ne deviendra pas un service comme github.com ou gitlab.com. Il n'héberge que gitea lui-même et nous vous recommandons de configurer vous-même l'instance gitea en fait.

@programmerjake C'est un serveur pont.

Je n'avais pas l'intention de m'éloigner de mon instance, mais je n'aime pas que ce projet repose sur une infrastructure donnée par une entreprise chinoise qui n'a presque aucune réputation dans le passé ou des résultats de recherche. Vous ne savez pas vraiment ce qu'ils feront à l'avenir ou s'ils exigent de réduire leur don si vous ne mettez pas en œuvre XY ou ne faites pas ZA ou s'ils s'en vont un jour.
Vous savez probablement ce que vous faites et mes préoccupations sont juste trop prudentes, mais vous ne le saurez jamais.

Pourquoi une entreprise chinoise le fera mais pas une entreprise américaine ? :)

Et je suis chinois, et tu devrais peut-être faire attention. Un jour, je pourrais voler vos codes. :)

Je pense que j'ai peut-être ce plan lorsque j'ai commencé Gogs avec 3 autres chinois en 2014.

Je n'avais pas l'intention de m'éloigner de mon instance, mais je n'aime pas que ce projet repose sur une infrastructure donnée par une entreprise chinoise. Vous ne savez pas vraiment ce qu'ils feront à l'avenir ou s'ils exigent de réduire leur don si vous ne mettez pas en œuvre XY ou ne faites pas ZA ou s'ils s'en vont un jour.
Vous savez probablement ce que vous faites et mes préoccupations sont juste trop prudentes, mais vous ne le saurez jamais.

C'est une réponse totalement idiote.
Maintenant, je suis peut-être plus ouvert d'esprit car je suis néerlandais, nous l'acceptons un peu. Vous devriez l'essayer aussi.

Tant que ce projet est open source, il n'y a à mon avis aucun risque pour ce que vous avez dit.
Et même s'ils le font, ce qui signifie probablement bifurquer Gitea, ils ont pleinement leur droit car la licence le permet simplement.

Les États-Unis cependant... permettez-moi de vous rappeler que Github a limité ses fonctionnalités maintenant en raison de la "guerre commerciale" entre les États-Unis et la Chine. Si quoi que ce soit, les États-Unis représentent plus un risque pour le développement de logiciels libres en ce moment que la Chine ne l'a jamais été. Zut, @lunny est probablement même effectué sur ce référentiel même en raison de la guerre commerciale.

@lunny et l'équipe de développement de Gitea. Continuez votre travail formidable ! :)

Et le premier objectif de gitea.com ne deviendra pas un service comme github.com ou gitlab.com. Il n'héberge que gitea lui-même et nous vous recommandons de configurer vous-même l'instance gitea en fait.

Est-ce quelque chose que vous pouvez envisager à l'avenir ?

Tant que ce projet est open source, il n'y a à mon avis aucun risque pour ce que vous avez dit.

Le projet principal n'a pas de risque, mais l'infrastructure en a. Il n'y a aucune garantie que le donateur inconnu et peu réputé sera là le mois prochain, peu importe s'il vient de n'importe où ou de Chine. GitHub sera là pendant longtemps et n'ira nulle part aussi vite.

De plus, si l'ensemble de l'infrastructure se déplace vers la Chine, l'ensemble de la base d'utilisateurs souffrira des difficultés entre les États-Unis et la Chine.

@lunny En
Évidemment, nous avons configuré des "sources fiables", comme GMail, Hotmail, etc. qui n'ont pas besoin de période de réflexion.

Les gens, si vous voulez plus d'infrastructures réparties dans chaque région, veuillez voter avec votre portefeuille sur https://opencollective.com/gitea

@SuperSandro2000 Savez-vous que Gitea n'est pas un service mais un _produit_ ? Vous téléchargez les sources, compilez Gitea dans vos serveurs et l'installez. Aucune connexion n'est requise à l'hébergement de Gitea.

s'ils exigent de réduire leur don si vous ne mettez pas en œuvre XY ou ne faites pas ZA ou s'ils partent un jour.

Rien ne garantit que le donateur inconnu et peu réputé sera là le mois prochain.

Quelques réponses à cela : Nous n'hébergerions pas une entreprise peu réputée, et les responsables de Gitea ont fait confiance à cette entreprise. S'ils cessent de parrainer ou d'être une entreprise, nous avons des options qui s'offrent à nous et pouvons déménager ailleurs.

toute la base d'utilisateurs souffrira des difficultés entre les États-Unis et la Chine.

Une grande partie de l'équipe Gitea vient de Chine (mais nous avons également des mainteneurs sur tous les autres continents), et si l'équipe de développement ne peut pas accéder au code, la base d'utilisateurs en souffrira, c'est pourquoi nous avons besoin d'une équipe de développement pour pouvoir accéder code. Nous construisons Gitea pour que tout le monde puisse l'utiliser, même les utilisateurs qui sont bannis de GitHub (après la récente vague d'interdiction de GitHub, beaucoup de ces utilisateurs ont commencé à utiliser Gitea).

Comme d'autres l'ont mentionné, il existe des miroirs de la base de code sur d'autres instances dans le monde, et grâce à git, il existe un registre de toutes les modifications apportées au code afin que tout le monde puisse avoir une visibilité sur toutes les modifications.

Une note sur la transparence : j'ai verrouillé ce fil. Je ne veux pas arrêter cette conversation, mais elle devrait être déplacée vers un autre endroit car ce ticket github concerne les améliorations à apporter au logiciel pour l'auto-hébergement (plutôt que l'endroit où nous hébergeons).