GitLab intends to remove free hosted projects that have been inactive for a year

GitLab plans to amend its terms of service in September, according to which projects hosted on GitLab.com hosting for free will be automatically deleted if their repositories remain inactive for 12 months. Rule changes have not yet been officially announced and are in the internal planning stage.

The change is aimed at reducing hosting maintenance costs by freeing up resources for storing and processing abandoned projects and non-developing forks. Maintaining the infrastructure for abandoned projects is estimated to account for up to a quarter of all GitLab.com hosting costs, and automatically purging such projects could save up to a million dollars a year.

Prior to actual deletion, notices will be sent to owners of repositories applying for deletion within a few weeks or months, warning them to confirm the relevance of the project. Only abandoned projects are planned to be deleted, the authors of which do not respond to warnings, no changes were noted in the repository during the year, no new issues were published, and no comments were sent.

However, some in the community consider the proposed removal to be a bad practice, as code from inactive repositories can be used as a dependency in other projects that remain active. It is also noted that permanent changes are not the goal of some authors, who may well consider that the current state of their project has reached an optimal level and the code is good enough and does not require improvement, or initially discover ready-made developments that are not planned to be developed, but which may be useful. surrounding.

In addition, the code of inactive projects can be referenced by external resources and deleting it will result in the loss of a verified master copy that can be referenced (unofficial copies are not guaranteed to be free of malicious activity), so instead of deleting, it would probably be more optimal to transfer to an archived state while maintaining the ability to access the code in read-only mode. To save disk space when storing garbage forks, you can use more efficient methods for handling duplicates, for example, GitHub stores all objects from the main repository and its associated forks together to avoid duplication of data, logically separating the ownership of commits.

Source: opennet.ru

Add a comment