We maintain repositories across GitLab and GitHub. I’d like to open a discussion about potentially consolidating all our repositories to GitHub.
Reasons to move to GitHub:
Upstream uses GitHub.
We’re forced to use GitHub for several repositories anyway (forks of upstream to facilicate PRs, clusters based on Launchpad because it relies on GitHub Actions).
Maintaining across two platforms increases our workload. We need to work with two different systems of CI config, different repo layout, etc. We need to manage permissions and groups on another platform. We need to configure services such as Renovate or Blacksmith separately for each platform.
Better discoverability for our public repos, and a central location to keep our private repos.
(this one is a minor, but personal) GitLab has an annoying bug where you can’t filter out archived repos when searching for issues (work_items).
Reasons to not change things:
We originally wanted to use GitLab as much as possible to support open source projects and/or an alternative to GitHub, and that may still apply.
Keeping the status quo is easier.
Migrating repos is work: links need updating, CI config needs rewriting, repo settings need porting.
Alternatively, we could consider other options, depending on where we sit on practicality and opensource ideology here.
Perhaps we could double down on using opensource platforms and move everything away GitHub except for forks of upstream projects - we can work on porting shared GitHub Actions to GitLab CI or CI-agnostic scripts. (I believe it’s a real issue that we have vendor-lockin to GitHub for our deployments now, but that’s perhaps a separate discussion.)
We could even host our own instance of GitLab, Sourcehut, Forgejo, etc. if we wanted to go hardcore. We could offer support and deployments for alternative code forges. The possibilities are endless (although the practicality is not)!
Anyway, I’m interested to hear your thoughts! Please let me know what you think, and also respond to the poll below to get a gauge of the general sentiment.
Thanks!
Do you think we should move all our repos to GitHub?
Should and worth are something need to be differentiated here. My main question: what issue do we want to solve with this? If that’s only “fragmentation”, then it doesn’t worth it, hence should not do it.
To be fair, I like GitHub way much more from UX perspective. However, I feel that it is a migration that doesn’t worth the enourmous time it requires. It is easy to underestimate how much it would take to move from A to B.
Moving away from GitHub is not possible with the constraints we work with at the moment.
This was the original idea. GitLab is the default for all new repos and most of what is left on GitHub is forks or just really old stuff that hasn’t been worth it to move. Which should tell you quite a bit about the costs about the prospect of switching.
Also GitHub has been doing everything possible to undermine my trust in it lately. The less we can rely on it the better. The move to Launchpad was a step backward in that regard, though I think it’s fair to say it’s an overall improvement on Grove.
We could but the downside is that it hinders collaboration with outside people, and we value that highly. GitLab is a pretty good middle-ground. It’s more open source than GitHub and we don’t use the enterprise elements, yet many developers have an account there even if they don’t use it often because they have at least one dependency that uses it.
I’d like to see us continue to avoid reliance on GitHub whenever possible, and look out for opportunities to move even further off of it. If we ever get to the point where GitHub is entirely too intolerable (which seems ever more likely day by day), it becomes much easier to leave.
For me the decision algorithm is simple on this type of topic:
Migrating from a closed-source tool (or partially like open core) to an open source tool => yes, unless there are strong UX blockers or requires too much budget
Migrating from an open source tool (or partially like open core) to something less open => no, especially for communication tools. And this is one where I would almost systematically use my veto, not just comment individually.
Yes, I wish I had realized that earlier - generally there hasn’t been enough discussions about Launchpad before doing the changes, both internally and with the larger community. We need to do better next time, otherwise we have to redo work already done, which isn’t great.
Talking about this, can we switch Launchpad back to gitlab, possibly supporting both options if others in the community want to keep using github?
Thanks for your comments everyone! I think this clarifies things nicely.
It would be nice to add (or re-add?) a note to the handbook about preferring creating repos on GitLab - currently it’s a bit random whether a repo ends up on GitHub or GitLab.
@gabor would know more, but as far as I can tell, the only tie that Launchpad has to GitHub are the use of GitHub actions. A summary:
build-all / build: this uses the Picasso build workflow which is specific to GitHub actions, and probably the hardest to migrate to another CI. However, this could be an excellent upstream contribution to untie Open edX deployments from GitHub. Also, I would appreciate being able to build images locally; this is the only piece of Launchpad that we can’t run locally right now as far as I know.
cleanup-container-packages: simply a quality of life periodic job to tidy the image repos; easily replaced, and the image repos are specific to the platform too.
create-instance / delete-instance / update-instance: rarely run, and easy to run locally (for the ayce deployment, I didn’t even include these, as they increased complexity)
pre-commit: some general lints - easily replaced
So if we can consider decoupling building images from GitHub - to at least be able to build them locally and from GitLab CI, that would let us move away from GitHub.
