GitLab supprimera les projets hébergés avec plus d'un an d'inactivité

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 de 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.


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Un commentaire, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   non nommé dit

    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/