In December meeting, we realised that it is not really maintained.
Thinking about it a bit more, for me, the less mental charge would be to keep it.
Then I guess we have 2 options:
keep it on the current VM
move it to IndieHosters infrastructure
As we host critical infra for our project (most of our source code is there) moving it to another member is not ok for me.
I can commit to maintain the GitLab there, on the current VM, but I’d like another person that commit with me.
Ideally if 2 people commit, as I do some other stuff, it would be nice, then I don’t have to handle that.
Either https://sr.ht or self-hosted. The approach is different from Gitlab, but it may be more adapted to smaller footprint while offering most of the same features needed in a librehoster setting. As this is experimental software it would require more involvement. Some people, including me, mentioned they would be interested in exploring this way.
Our member Web Architects run a Gitlab already at git.coop. I’m not sure why it would be problematic for Indie.hosters to maintain their code outside of their own infra, but this question set aside, I see no reason why code outside of libre.sh could not go there.
3. Indie Hosters Gitlab
As proposed by @pierreozoux and @unteem, we could move all repositories to their infrastructure.
4. Status Quo
Since nobody seems interested in maintaining an extra Gitlab for the specific usage of librehosters, I think it should be shut down and another option chosen.
We currently pay the VM, but it is something like 10e/month, it is not about the price, it is about sysadmin time to maintain the stack.
If libreho.st doesn’t need it’s own gitlab, it is also fine, but the least time consuming option for me and libre.sh, is to keep lab.libreho.st as it is.
So basically, I don’t have an opinion for the projects hosted by lab.libreho.st.
My main interest is the libre.sh org hosted on lab.libreho.st.
If librehosters decides they don’t need their own gitlab, then we’ll probably change the name of the GitLab, but it’ll require some work,but well, that’s life.
I think the simplest path is to maintain the current VM , I can help but we need to define precisely who is admin and who is in charge in case of problem