Move and migrate GTG over to Gitlab

[heavensmile]

Given that basically the entire GNOME project is hosted on Gitlab these days I think it would make sense to consider migrate GTG over to GNOME’s Gitlab instance as well.

I think its safe to state that a move to Gitlab could attract more interest and contributors to GTG (a migration would at least expose GTG to more GNOME community members).

A move over to Gitlab might also increase the trustworthiness of GTG as an attractive GNOME app [0].

Feedback on this proposal is very much *welcome.

0 especially as I understand that there is an ongoing effort to revive the project
*including info about the requirements/steps necessary for a move.

[nekohayo]

I'm not particularly for/against the idea, though I'll throw in a few thoughts here:

• Unless other maintainers feel strongly in favor of this, I don't think I'd have that as a priority, personally speaking.
  • We need to focus on making a release, and GitHub is "good enough". Diving back into infrastructure work is a distraction from the goal of making a release.
  • I know of no features in GitLab that I miss on GitHub, except the theoretical "it's slightly more Free" because it's open-core (so not totally Free).
  • Not only does GTG have many tickets to migrate (I hope that can be automated, can it?), it has multiple modules/subprojects, a CI suite (I have no idea how it works), etc.
  • I don't think I would be the one to be doing the infrastructure migration work, I haven't got the time+patience+skills for that. It would need to be done by the GNOME sysadmins/infra team as a "turn-key" service basically. We haven't even properly migrated/killed off the LaunchPad project page where most of the GTG development was until "recently" in its history...
• I'd like to see proof of the massive uptake in contributions when on GitLab vs GitHub (not "GNOME GitLab vs Bugzilla"). GNOME contributors already have a gitlab account, but they also typically already have a GitHub account; the reverse is not always true; it can be argued that except for those who distrust GitHub as a hosting platform out of principle, being here provides broader appeal / lower barriers to contributions.

[heavensmile]

Jeff thanks for your reply I think your arguments, in general, makes sense.

That said I do not think that there is an overstatement that Github is a proprietary platform and that Gitlab can be considered as the natural home for GNOME apps these days (but again I understand your concerns).

*I consider to further look into and investigate how migration would work (that would in itself represent a good learning exercise for me).

[nekohayo]

Yeah well, before GitLab, for decades people were using SourceForge (proprietary), LaunchPad (proprietary for half a decade), and a plethora of other things, and nobody died. If GitLab was 100% Free and Open-Source software I would hear the "it's better because it's Free" argument, but considering it's open-core only, I find that argument less clear-cut and convincing.

I guess I've also been bitten by too many platform migrations for a plethora of projects I've participated in... people switching across SF, Trac, GitHub, Bugzilla, Phabricator, Taïga, Gogs, Savannah, Redmine, Mantis... you name it I've seen it, and it's usually been a duck-tape hackjob everytime ;) hence why if a bunch of others are seeing a real benefit from this and the transition can be done "turn-key"/painlessly, I won't stop 'em (GitLab being the only one I could accept migrating to because it's "not crap like the rest"), but I will have no personal interest in spending my own time and energy on this infrastructure endeavour. Just my 2¢ :)

[diegogangl]

I'm in favor of moving to Gnome's Gitlab. But if we decide to go for it we should do it after 0.4 or right before launching. That way we will have 0 PRs and few open tickets to export.
I didn't have any issues when I moved my own projects to Gitlab, but they were kind of simple (it was only me). I don't think we should worry about CI. It's super broken and it looks like it's going to be a lot of work anyways.

My reasons to go for Gitlab:

• Serendipity. I often see familiar faces popping up in random projects, I'm sure we would get more drive-by contributions. For instance, there's an initiative about having keyboard shortcut windows in every Gnome app and some guy is going around opening tickets with a checklist for every project.
• Gnome's Gitlab has some CI-thingie-feature that lets them generate nightly flatpaks for testers. Bilal mentioned this in Create and maintain official Flatpak packages on Flathub #233

[heavensmile]

Just to state things a bit more clearly, an important reason why I think that a move to Gitlab would make sense is because I think Gitlab can yes be considered as the natural home for GNOME apps these days.

Understand and agree btw @diegogangl that a possible move to Gitlab makes sense first after, or right before a possible 0.4 release.

*I’m likely to keep an eye on this ticket (and the project in general).

[nekohayo]

With further thinking, benefitting from the work of GNOME translation teams would be my single reason for wanting to move everything to it. It kinda sounds like we have no choice because it seems LaunchPad is a ghost town even for translations anyway, and I kinda doubt people are going to manually send po files at us.

Now, for this migration to happen, we'll really need the GNOME sysadmins to be fully on board to support us with this in a way that it can be done "in one go", because of the old proverb: nothing is as permanent as a temporary situation. And we can't afford to stay paralyzed in limbo when we're trying to resurrect this project.

Things that "must" be migrated:

• Code (obviously)
• All tickets, preserving:
  • the ticket numbers and cross-linking
  • assigned/commenting users (not something messy like the Bugzilla migration was, where things were assigned to or commented by a "bot" rather than associated to the equivalent user email addresses) and subscribers
  • labels and milestones (including for closed tickets)
  • attached files/images

Ideally, also merge requests (like tickets)

I wasn't totally sure if GitLab imports all that, but it seems like it? https://docs.gitlab.com/ee/user/project/import/github.html

Other considerations:

• We need to be able to import our "group" of projects, that is https://github.com/getting-things-gnome/, ideally all as a nice tidy group that people can look at and find the stuff. I often found GitLab to be a labyrinth in this regard.
• We'd need a way to turn off the bug tracker / tickets in GitHub afterwards, and to have the tickets redirect (or at least link) to their new locations

[nekohayo]

For anyone looking at this and wondering why this is not yet done: we would need solid and responsive support from (a) GNOME infrastructures/sysadmin team member(s) to ensure this is done properly, in one fell swoop, with everything migrated properly and verified... and so far we haven't been able to actually get a hold of a dedicated GNOME infrastructure team member that would be able to work on this with us. @diegogangl has tried reaching out to various people and is so far not getting a response.

While he has been able to do some non-root migration experiments I think he ran into some limitations due to not being an admin on GNOME's infrastructure (I don't quite remember what not, because it's been a while since we last discussed it)...

[nekohayo]

Just to document a bit for the future when we may have time to consider this again someday: the procedure for getting "developer" permission levels in GNOME's gitlab is documented in this wiki page and is mostly about filing tickets with the correct template in the "Infrastructure/infrastructure" component (and not elsewhere).

I suspect we will need that and probably another ticket (first?) to request the proper creation of the project module (instead of stuff being under a personal account's namespace), etc etc. Probably documented somewhere in that wiki (specifically this page?), or worth discussing with the team on Matrix (see their contact page).