Maybe that’s a dumb question, but is it planned to host Mastodon Git repository not on GitHub (you know Microsoft)?
Indeed, it makes sense to host the main development to something that facilitates participation (e.g., Gitlab, Gitea), and maintain mirrors to ‘the others’. I didn’t look at Gods in ages, so I’m not sure where Gitea/Gogs stand compared to Github and Gitlab in terms of community features.
I know Discourse is integrating well with Github, and would expect it to do that well with Gitlab in the near future.
@Gargron another option is to move Mastodon dev to an existing GitLab instance run by a like-minded community:
Of course, this isn’t an either / or. Once you have everything on GL, everything is a Git repo, not just the source code, but issues, wikis, everything. This means exporting a whole project from one GL instance to another is pretty trivial. As I understand it (although I haven’t tried), it’s just a bunch of git pull and git push.
I intend to gradually move related repositories over to my new GitLab. However there is a large risk and cost associated with actually moving tootsuite/mastodon:
- Fork ecosystem based on GitHub referencing
- Pull request history
- Commits referencing GitHub issues by numbers
- A lot of websites linking to the GitHub
- The GitHub repository is the top result in search, but GitLab won’t be for a very long time if ever
- A lot of people would have to
git remote set-url origin https://new-url-here
Other people have also raised the concern that the move would amplify the bus factor, since the GitLab could go down in my absence unless a lot of people have sysadmin access.
So, we’ll take it slow, Main repository won’t move yet, and Mastodon v2.4.1 just came out still linking to GitHub. Maybe next version.
Like you say, it doesn’t have to be a hard either/ or. You can leave a mirror on GH, with an automated backup of the latest version of the code (and any dev branches etc), but move your own activity to the GL, and leave LuggageTags on the GH pages encouraging others to do the same. If the GL goes down, the GH is still there as a backup.
But since you’re doing good delegation and succession planning (I hope!), that will include bringing in other sysadmins to feed and water the GL and any other self-hosted project tools, that will reduce downtime anyway. There is also scope for working together with others who are self-hosting GL (or are wanting to), either by pooling your sysadmin efforts, or having fewer, larger instances. This includes the social.coop folks, who are currently deciding between using git.coop or hosting an instance, or any of these folks.
Having said all that, and without wanting in any way to bring drama into this thread, there is about to be some major disruptions/ changes brought about by the #ForkOffTogether folks decamping. This seems like an idea time to re-evaluate your dev toolset and make any changes you plan to make eventually. Unlike on GH, on a self-hosted GL the project admins have the power to put people verbally abusing others on moderation, or suspend their account. Just saying …
IMO it would be a mistake to maintain your own Gitlab instance. There’s a number of reasons for this, the main one being that the whole interest of a Web interface to your repositories is the collective action that can take place there : it would be so much better to use an existing instance where many people are already active. I know Github is the preferred place for rubyists, so it’s a tough call to move away from it and find a suitable replacement. Gitlab.com itself is a problematic choice since it’s also funded by U.S. Venture Capital – so not so far from the Github model besides the open core model. Gitlab has been behaving relatively acceptably in the last years, although the risk of a buy out remains. Framagit.org uses Gitlab CE software and is operated by a non-profit with clear political engagement with free software.
The ideal case would be that public money pays for public digital infrastructure, but we’re far from it, especially with the recent decision by EU Council to support Article 13 (“censorship machines”) amendment to the EU Copyright reform. So if you’re serious about moving away from Github, I’d suggest to go to an existing Gitlab – so you have the benefit of social interaction without the burden of maintenance, and follow the discussions within the community to orientate free software development efforts towards publicly supported platforms – and by publicly here, I’m certainly not thinking about government control but community-operated.
I see @strypey linking to a number of Gitlab instances : yes, why would each project setup their own? Don’t you have enough on your hands already? And these instances are not federated! So here, you have my opinion. @Gargron I like you doing what you like best, and I’m not sure maintaining a Gitlab is what you want – although I know by experience that maintaining a Gitlab is usually painless.
True, although hopefully that will be changing in the near future, thanks to the work being done on GitPub.
This will take time anyway.