Neat, must remember to put bugs into code so it has to be continuously revised
XYZZY (sorry, the post must contain letters, even if the title has all the content.)
GitLab has reversed its decision to automatically delete projects that are inactive for more than a year and belong to its free-tier users. As revealed exclusively yesterday by The Register, GitLab planned to introduce the policy in late September. The biz hoped the move would save it up to $1 million a year and help make its …
if the reason for "dormancy" is either 'legacy' or 'was written correctly and needs no fixing', then there needs to be a different metric other than "no commits for the last xxx days". In fact, a STABLE project that RARELY (if ever) changes COULD be the ideal library or utility to include with your product or services... until it gets wiped away because "it has not been 'maintained'".
Even going into slow storage may be completely inappropriate. I hope they consider how often it is cloned or downloaded in that calculation...
Unless it is being used by one of those "must get a new copy from the 'Net every build" setups, a stable library may still only see a very few downloads, when new projects grab their copy to go into the local repo.
Though if you are including in "downloads" polling for updates, hopefully that would put the numbers up a bit.
If it's a commonly used library there are probably enough projects doing "let's download anyway because it's aa convenient a way as any to check" and if it's an application there are probably enough people who download because it's not in their OS's app store/repo.
If you look on SourceForge there can be a surprising number of downloads listed for something you might have thought was niche or dead. And even if there aren't it's still there.
This is the repository parallel to "this ticket has been automatically closed because there has been no activity".
We fixed the problem of too many open tickets by breaking the ticket system. We fixed the problem of too much source code by deleting the source code. See, this stuff was *easy* to automate, I don't know why we didn't think of this before! What do you mean "problem of too many employees?"
I work for a company that says you can only use an open-source library if it's had some commits this year.
So obviously I maintain a fork of the stable library I want to use, and I update its copyright date every year.
This would have amounted to pouring salt in the wound, or a near complete betrayal by Gitlab after all of the effort and on-line buzz it generated a little more than a year ago encouraging Github users to migrate projects to Gitlab. Curious the proposed deletion of free projects comes just about one year after that big push. Almost like they were surprised they got what they asked for -- but forgot to factor in storage costs.
Worse the relatives who have cleared out your father's home before you arrive at the funeral. Valuable, rare, precious and sentimental things all unceremoniously dumped in the bin and lost forever to landfill, mine and his included.
"Other internal documents seen by The Register mention the possible use of object storage to archive projects but express concerns that doing so would increase GitLab’s costs by creating a need for multiple redundant backups."
Eh, if you want to be a successful project-hosting company on a massive scale, these contingencies should already be baked into your business plan. Your success should not be the cause of your failure.
Arguably one possiblity with many of these "free" situations is that the company might contemplate a sale of itself, but has been given advice, or told by potential buyers that the "free" element is a drain on future profits, and therefore an unattractive proposition which must be got shot of before offers can be made.
The flip-side is that any company wanting to stay independent could use this as a "poison pill" to discourage unwanted predators.
“ Archived projects docs.gitlab.com/ee/user/projec… is 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 storage gitlab.com/groups/gitlab-… would keep the repos visible to everyone.”
What the fuck is orthogonal?
Simple - using cron, setup a bash script to go through the repo and insert a top comment saying - 'This text inserted because GITLAB are a bunch of clowns 0001'
Set the script to increment 0001 accordingly, and delete the previously inserted lines - And There you go.
You get the best of both worlds - 1 - You save your project from deletion, and 2 - You make GITLAB the most active repository on the planet! And nobody has to pay for it - it's all free - all of the storage and bandwidth!
Go Open Source.
U-turns teach you a lot about what people know about but are not talking about. A "U-turn" is always presented as a "solution" ( unless you are a Brexiter, LOL) even if you are announcing other U-turns all the time to get new votes.
U-turns are not a solution or a problem, they simply give us clues about what's "going on" but not happening.
Since I really don't know, could they, lets say, reduce the amount of free storage to something like 1GB and save a chuck of change? How many of these repos are even over that size?
I don't seeing it saving the full 80%, but I can see it saving 50%. Unless someone cares to enlighten me why this won't save as much as I think.
Biting the hand that feeds IT © 1998–2022