Just wondering about the move to Gitlab - is there an actionable list somewhere of things that need to be done? If you don't know, GNOME's had a pretty nice looking self-hosted Gitlab for years now [1].
Currently the OpenWrt project is spread across: Github, git.openwrt.org, and Flyspray, not to mention the IRC, forum, wiki and mailing lists (but I am not saying the latter four being separate is necessarily an issue).
Issues with the current set of tools:
- Github: no self host option
-
git.openwrt.org: fine for basic hosting, but lacking a lot of features
- flyspray: lacking a lot of features, for instance doesn't have code highlighting in patches; can't be easily referenced in the related pull requests
The biggest advantage of a move to self hosted Gitlab is consolidating all the issue tracking, CI, and hosting in one place, making it easier to contribute to the project, just like it did for GNOME, instead of logging in to three or more different sites that are all built with different technologies, UI's, have different latency when accessing them - and that's just for the user. The other side of it is the question of backups, administration etc.
And of course it is all easier said than done, but just wanted to point out that it looks like Gitlab will actually help an org like OpenWrt migrate to any Gitlab instance [2]
- https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
- https://gitlab.com/gitlab-org/gitlab-foss/-/issues/40541
2 Likes
In about an hour I was able to complete a dry run migration to GitLab.com (not self-hosted) for my forks of the OpenWrt core, LuCI and packages repositories and so far it seems to have pulled the code over painlessly (no big surprise). However, I cannot test import of issues, merge requests, and all that other stuff, because I am only copying my fork over, not the real repository. A repository owner will need to test those features. But, according to GitLab, all of that is supported.
On the other hand, what I can report that is at least semi-useful is it looks like the self-hosted GitLab will need to have GitHub integration enabled because that is not enabled by default in self-hosted installations. This feature allows login with GitHub.
The second point is that it may be a good idea to ask people to create their GitLab account ahead of the migration, if they want to be sure their profiles are matched with their new GitLab account.
Scrolling through the commit log, it appears that lot of contributors already have a GitLab account, either by creating one or by logging into GitLab with GitHub at some point in time, because many authors look the same as they do on GitHub (name, avatar). How that works.
Use the GitHub integration
Before you begin, ensure that any GitHub users who you want to map to GitLab users have either:
- A GitLab account that has logged in using the Login with GitHub icon - or -
- A GitLab account with an email address that matches the publicly visible email address in the profile of the GitHub user
User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with the user account that is performing the import.
If you are using a self-managed GitLab instance or if you are importing from GitHub Enterprise, this process requires that you have configured GitHub integration.