La société GitLab prévoit en septembre d'apporter des modifications aux règles d'utilisation de son service, selon lesquelles les projets hébergés gratuitement sur GitLab.com seront automatiquement supprimés si leurs dépôts restent inactifs pendant 12 mois. Les modifications des règles n'ont pas encore été officiellement annoncées et sont en cours de planification interne.
Le changement vise à réduire les coûts de maintenance de l'hébergement en libérant des ressources pour le stockage et le traitement des projets abandonnés et des forks non développés. On estime que jusqu'à un quart de tous les coûts d'exploitation est consacré à la maintenance de l'infrastructure pour les projets abandonnés. d'hébergement GitLab.com et le nettoyage automatique de tels projets pourraient permettre d'économiser jusqu'à un million de dollars par an.
Avant la suppression effective, les propriétaires des dépôts concernés recevront des notifications pendant plusieurs semaines ou mois, les avertissant de la nécessité de confirmer la pertinence du projet. Seuls les projets abandonnés seront supprimés, lorsque les auteurs ne réagissent pas aux avertissements, qu'il n'y a eu aucune modification dans le dépôt pendant un an, aucun nouvel issue n'a été publié et aucun commentaire a été envoyé.
Cependant, certains membres de la communauté considèrent cette suppression proposée comme une pratique douteuse, car le code des dépôts inactifs peut être utilisé comme dépendance dans d'autres projets toujours actifs. Il est également noté que de nombreux auteurs n'ont pas pour objectif d'apporter des modifications constantes et peuvent estimer que l'état actuel de leur projet est optimal, que le code est suffisamment bon et ne nécessite pas d'améliorations, ou qu'ils préfèrent publier des travaux achevés qui ne seront pas développés mais qui pourraient s'avérer utiles pour les autres.
De plus, le code des projets inactifs peut être référencé par des ressources externes, et sa suppression entraînera la perte d'une copie de référence confirmée, à laquelle on peut se référer (les copies non officielles ne garantissent pas l'absence d'activité malveillante). Ainsi, au lieu de supprimer, il serait probablement plus optimal de le transférer dans un état d'archivage tout en conservant l'accès au code en mode lecture seule. Pour économiser de l'espace disque lors du stockage de forks inutiles, des méthodes de traitement des doublons plus efficaces peuvent être appliquées. Par exemple, GitHub conserve tous les objets du dépôt principal et des forks associés en évitant la duplication de données, en séparant logiquement l'appartenance des commits.
Source : opennet.ru
