Which Gitlab? The software is less important than the ecosystem. Git is the major component, but Github/Gitlab are about usefully centralizing it. Gitlab is still a centralized service, even if there are N instances of centralization.
In other words, I don't know how much use it is to fork Gitlab if the community around it is dispersed. Git is already based around decentralization, and I don't see how running my own instance of Gitlab makes it any less disruptive when the most popular instance of Gitlab is disbanded.
But how do you transport your issues and CI integration and deployment? The googlecode to github transport was already a desaster.
Code is easy, it's the rest which has the value.
Which Gitlab? The software is less important than the ecosystem. Git is the major component, but Github/Gitlab are about usefully centralizing it. Gitlab is still a centralized service, even if there are N instances of centralization.
In other words, I don't know how much use it is to fork Gitlab if the community around it is dispersed. Git is already based around decentralization, and I don't see how running my own instance of Gitlab makes it any less disruptive when the most popular instance of Gitlab is disbanded.
Hmm, if there are N instances of centralization, that is still more decentralized than N=1 instances.
Well you don't need to. You can use gitlab or gitea.
But how do you transport your issues and CI integration and deployment? The googlecode to github transport was already a desaster. Code is easy, it's the rest which has the value.
https://developer.github.com/v3/issues/#list-issues then reimport it with whatever your target system provides.
Edit your CI scripts. Your CI should not be dependent on Github to work, besides maybe pulling code from it. But then it's just a simple change.
1 reply →