Reminder: check out what GitLab has put in place for “dormant” or “inactive” repositories
Posted by jpluimers on 2024/10/31
A few of my git repositories and technical surroundings (like pages) should outlast my life expectancy, for instance the ones supporting the IT infrastructure of my mentally retarded brother after I pass away.
Most of the involved repositories have no write-activity (they are either documentation that the people can use after I passed away, or are semi-static web-pages that require TLS in order to keep functioning; GitLab provides an automatic update mechanism for that which is based on Let’s Encrypt).
Summer 2022, GitLab caused quite some stir when they planned to first delete dormant repositories. Links on tose below.
Of course I could move to GitHub, but that lacks access control through project hierarchy provided by GitLab and could implement a similar repository dormancy scheme in the future.
Using an external “keepalive” mechanism only induces a game of walls and ladders [Wayback/Archive] (likely requiring intervention after I die) and also makes the infrastructure more brittle so I proposed a lump sum plan.
Some links for my reminder:
- [Wayback/Archive] jilles.com on Twitter: “GitLab plans to delete dormant projects in free accounts”
- [Wayback/Archive] GitLab plans to delete dormant projects from free accounts • The Register
GitLab is aware of the potential for angry opposition to the plan, and will therefore give users weeks or months of warning before deleting their work. A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive.
- [Wayback/Archive] GitLab plans to delete dormant projects from free accounts • The Register
- [Wayback/Archive] jilles.com on Twitter: “UPDATE: GitLab U-turns on deleting dormant projects after backlash”
- [Wayback/Archive] GitLab U-turns on deleting dormant projects after backlash • The Register
El Reg understands GitLab’s plan to delete inactive projects saw The Internet Archive and code preservation organisation Software Heritage begin planning to preserve the GitLab trove.
- [Wayback/Archive] GitLab U-turns on deleting dormant projects after backlash • The Register
- [Wayback/Archive] GitLab wil inactieve projecten bij gratis gebruikers na een jaar verwijderen – IT Pro – Nieuws – Tweakers
- [Wayback/Archive] GitLab gaat toch geen inactieve projecten verwijderen – IT Pro – Nieuws – Tweakers
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@simonw I asked another question:”
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@gitlab Will GitLab pages that depend on those repositories keep working (including Let’s Encrypt backed TLS)? I have a few of those and would love for them to stay online after I will pass away.”
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@gitlab I wish there was a pay-forward lump-sum kind of “subscription” for this, as I really do not mind paying, especially not for the projects my mentally retarded brother depends on after I pass away (which given my health situation is likely to happen within 10 years).”
- [Wayback/Archive] GitLab on Twitter: “We discussed internally what to do with inactive repositories. We reached a decision to move unused repos to object storage. Once implemented, they will still be accessible but take a bit longer to access after a long period of inactivity.”
- [Wayback/Archive] Daniel Carosone on Twitter: “@gitlab This is much better and entirely reasonable, especially if it is (as implied) based more on read access than write activity. But sadly now people will be wary, including that you didn’t start here as a simple, transparent operational optimisation”
- [Wayback/Archive] Jakob on Twitter: “@gitlab Wait, does “inactive” mean repositories that have no new commits? Or only those without new commits AND without read access by cloning / fetching?”
- [Wayback/Archive] Sid Sijbrandij on Twitter: “@odoruhako @gitlab We’re not sure yet. Probably all write operations would keep a project active, creating an issue, a merge request, pushing changes to a branch, etc. We might also keep it active as long as people are doing read operations such as cloning, forking, etc.”
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@sytses @odoruhako @gitlab Did GitLab ever consider a lump sum plan? It would ease many things given my (health induced) life expectancy as I need to at least ensure the parts of my mentally retarded brother’s IT infrastructure keeps working for quite some time after I pass away”
- [Wayback/Archive] Simon Willison on Twitter: “@gitlab Will the archived code still be visible to the public or will only the repository owner be able to recover it from the archived object storage?”
- [Wayback/Archive] Simon Willison on Twitter: “@gitlab If only the owner can recover it, have you considered the deeply unfortunate where a project owner maintainer dies and their code all becomes inaccessible a year after they cease activity on the site?”
- [Wayback/Archive] Sid Sijbrandij on Twitter: “@simonw @gitlab Archived projects
docs.gitlab.com/ee/user/project/settingshttps://docs.gitlab.com/ee/user/project/settings/#archive-a-projectis a user activated state that signals intent. We’re not sure yet but very likely the storage type used is orthogonal to that. Our current plan for object storagegitlab.com/groups/gitlab-org/-/epics/4959would keep the repos visible to everyone.”
I disagree a bit with Daniel Carosone with his “But sadly now people will be wary” as the inherent risk of using “free” things always mean the can (and likely will) stop being free.
Hopefully by now there is a lump-sum way (or another party providing a lump sum way) of hosting a Let’s Encrypt backed set of pages that are being retrieved from an underlying git repository.
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment