Récemment, la nouvelle a annoncé que GitLab envisage de modifier ses conditions d'utilisation pour le mois suivant (en septembre), selon lequel le projets hébergés sur des comptes gratuits depuis GitLab.com sera supprimé automatiquement si vos référentiels restent inactifs pendant 12 mois.
Le changement vise à réduire les coûts de maintenance d'hébergement en libérant des ressources pour stocker et traiter les projets abandonnés et les forks qui ne sont pas en cours de développement.
On estime que la maintenance de l'infrastructure des projets abandonnés représente jusqu'à un quart de tous les coûts d'hébergement de GitLab.com, et la purge automatique de ces projets pourrait permettre d'économiser jusqu'à un million de dollars par an.
Le registre a appris que ces projets représentent jusqu'à un quart des coûts d'hébergement de GitLab, et que la suppression automatique des projets pourrait permettre au service de collaboration de codage dans le cloud d'économiser jusqu'à 1 million de dollars par an. Par conséquent, la politique a été suggérée pour aider à assurer la pérennité des finances de GitLab.
Des personnes au courant de la situation, qui ont demandé l'anonymat car elles ne sont pas autorisées à en discuter avec les médias, ont déclaré à The Register que la politique entrera en vigueur en septembre 2022.
Avant le déménagement proprement dit, en quelques semaines ou mois, des notifications seront envoyées aux propriétaires du dépôt qui demandent la suppression avec un avertissement pour confirmer la pertinence du projet. Seuls les projets abandonnés sont censés être supprimés, dont les auteurs ne répondent pas aux avertissements, aucun changement n'a été enregistré dans le référentiel au cours de l'année, aucun nouveau numéro n'a été publié et aucun commentaire n'a été envoyé.
Cependant, certains les membres de la communauté considèrent que le retrait proposé est une mauvaise pratique, puisque le code des dépôts inactifs peut être utilisé comme dépendance dans d'autres projets qui restent actifs.
On note également que les changements permanents ne sont pas le but de certains auteurs, qui peuvent soit considérer que l'état actuel de leur projet a atteint un niveau optimal, et que le code est assez bon et ne nécessite pas d'améliorations, soit découvrir dans un premier temps qu'ils sont pas prévu d'être développé, mais qui peut être utile à votre entourage.
Geoff Huntley, défenseur de l'open source et membre de la communauté ouverte .Net, a décrit la politique comme "absolument sauvage".
« Le code source n'occupe pas beaucoup d'espace disque, si quelqu'un supprime tout ce code, c'est la destruction de la communauté. Ils détruiront votre marque et votre bonne volonté. Les gens y hébergent leur code parce qu'il y a une idée qu'il sera disponible au grand public pour être réutilisé et remixé.
Bien sûr, il n'y a aucune garantie qu'il y sera toujours hébergé, mais les règles non écrites de l'open source sont que vous rendez le code disponible et que vous ne le supprimez pas. Nous avons demandé à des mainteneurs de retirer le code et il y a eu beaucoup d'indignation dans la communauté à ce sujet", a-t-il déclaré, notant que d'autres projets qui dépendent d'un produit retiré en souffriront.
"Toutes les dépendances ne peuvent pas être compilées", a-t-il déploré.
En outre, le code des projets inactifs peut être référencé par des ressources externes et, en le retirant, une copie maître vérifiée sera perdue qui peut être référencé (les copies non officielles ne sont pas garanties exemptes d'activité malveillante), donc au lieu de supprimer, il serait probablement plus optimal d'archiver l'état tout en conservant la possibilité d'accéder au code en mode lecture seule.
Pour économiser de l'espace disque lors du stockage des fourches de récupération, vous pouvez utiliser des méthodes plus efficaces pour gérer les doublons, par exemple, GitHub stocke ensemble tous les objets du référentiel principal et leurs fourches associées pour éviter la duplication des données, en séparant logiquement la propriété des validations.
Enfin, il convient de mentionner que les changements de règles n'ont pas encore été officiellement annoncés et sont au stade de la planification interne.
Enfin, pour ceux qui souhaitent en savoir plus à propos de la note, vous pouvez consulter la publication originale dans le lien suivant.
il se passe quelque chose dans gitlab, en effet certains projets envisagent de migrer vers d'autres plateformes, comme c'est le cas avec postmarketOS : https://postmarketos.org/blog/2022/07/25/considering-sourcehut/