Federation in GitLab CE #174

New issue

fr33domlover · 2022-09-29T06:53:40Z

fr33domlover commented

2022-09-29 06:53:40 +00:00

So, how do we get ForgeFed into GitLab?

It's a huge, complicated piece of software
It's being used by many FLOSS projects
It's being developed by a company - how much is the community involved, how much work is done via MRs from people who aren't GitLab employees?
They don't seem excited about federation last time I checked, probably because their customers don't need/want it so there's no m0ney incentive in working on it
It seems federation requires changes to the core of an app - what if the GitLab company doesn't want to make such changes? Is it realistic to implement federation in a fork, or a separate component/plugin?

I collected a list of GitLab issues and MRs that are somehow related to federation. I'll go over them another time; for now, listing them here for everyone to see. It seems GitLab.com now requires to register before you can to free text search in their issues and MRs. Probably because it's a heavy operation and they don't want bots and spam to trigger it?

If you want a quick look, try the 1st issue on this list, it was opened by a ForgeFed team member.

Possible strategies to get federation into GitLab CE:

Talk with them about how to implement federation even if they don't want to active support it - will they review related MRs? Will they allow changes to core DB schemas? See if we can figure it out together with them
Public email/issue campaign to convince them the community wants this (pressure via publicity?)
Have people study GitLab's architecture and assess the complexity of adding federation, and find a reasonable work plan
Ask people using gitlab.com to add a section to their README.md, asking GitLab to support the community's effort to add federation :P
Do they need our help finding funding, so they can allocate a developer on their company to this? Probably not, they have their huge income already, but, who knows, let's help them if that's what it takes

So, how do we get ForgeFed into GitLab? - It's a huge, complicated piece of software - It's being used by many FLOSS projects - It's being developed by a company - how much is the community involved, how much work is done via MRs from people who aren't GitLab employees? - They don't seem excited about federation last time I checked, probably because their customers don't need/want it so there's no m0ney incentive in working on it - It seems federation requires changes to the core of an app - what if the GitLab company doesn't want to make such changes? Is it realistic to implement federation in a fork, or a separate component/plugin? I collected a list of GitLab issues and MRs that are somehow related to federation. I'll go over them another time; for now, listing them here for everyone to see. It seems GitLab.com now requires to register before you can to free text search in their issues and MRs. Probably because it's a heavy operation and they don't want bots and spam to trigger it? - [#30672 Federating GitLab through ForgeFed-ActivityPub](https://gitlab.com/gitlab-org/gitlab/-/issues/30672) - [&260 Distributed merge requests](https://gitlab.com/groups/gitlab-org/-/epics/260) - [&7582 GitLab Pods](https://gitlab.com/groups/gitlab-org/-/epics/7582) - [&8437 Pods - Proof of Concepts](https://gitlab.com/groups/gitlab-org/-/epics/8437) - [&6221 Federated Advanced Global Search for Self-Managed](https://gitlab.com/groups/gitlab-org/-/epics/6221) - [&6037 GitLab Regions](https://gitlab.com/groups/gitlab-org/-/epics/6037) - [#6468 Federated GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/6468) - [!18298 WIP: Federation Enhancements: Identity Model](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18298) - [#8411 Geo: Secondary-first MRs](https://gitlab.com/gitlab-org/gitlab/-/issues/8411) - [#21582 Share events externally via ActivityPub](https://gitlab.com/gitlab-org/gitlab/-/issues/21582) - [#23406 [Profile] Add ActivityPub/Mastodon address to profile page](https://gitlab.com/gitlab-org/gitlab/-/issues/23406) - [#15383 Webmention support](https://gitlab.com/gitlab-org/gitlab/-/issues/15383) - [#14116 Implement cross-server (federated) merge requests](https://gitlab.com/gitlab-org/gitlab/-/issues/14116) - https://gitlab.com/gitlab-org/gitlab/-/issues/15691 - https://gitlab.com/gitlab-org/gitlab/-/issues/371652 - https://gitlab.com/gitlab-org/gitlab/-/issues/347085 - https://gitlab.com/gitlab-org/gitlab/-/issues/339311 - https://gitlab.com/gitlab-org/gitlab/-/issues/299577 - https://gitlab.com/gitlab-org/gitlab/-/issues/281051 - https://gitlab.com/gitlab-org/gitlab/-/issues/223138 - https://gitlab.com/gitlab-org/gitlab/-/issues/220991 - https://gitlab.com/gitlab-org/gitlab/-/issues/208874 - https://gitlab.com/gitlab-org/gitlab/-/issues/37981 - https://gitlab.com/gitlab-org/gitlab/-/issues/34255 - https://gitlab.com/gitlab-org/gitlab/-/issues/33665 - https://gitlab.com/gitlab-org/gitlab/-/issues/32389 - https://gitlab.com/gitlab-org/gitlab/-/issues/32372 - https://gitlab.com/gitlab-org/gitlab/-/issues/30672 - https://gitlab.com/gitlab-org/gitlab/-/issues/11592 - https://gitlab.com/gitlab-org/gitlab/-/issues/23153 - https://gitlab.com/gitlab-org/gitlab/-/issues/22996 - https://gitlab.com/gitlab-org/gitlab/-/issues/6468 - https://gitlab.com/gitlab-org/gitlab/-/issues/4517 - https://gitlab.com/gitlab-org/gitlab/-/issues/19042 - https://gitlab.com/gitlab-org/gitlab/-/issues/17791 If you want a quick look, try the 1st issue on this list, it was opened by a ForgeFed team member. Possible strategies to get federation into GitLab CE: - Talk with them about how to implement federation even if they don't want to active support it - will they review related MRs? Will they allow changes to core DB schemas? See if we can figure it out together with them - Public email/issue campaign to convince them the community wants this (pressure via publicity?) - Have people study GitLab's architecture and assess the complexity of adding federation, and find a reasonable work plan - Ask people using gitlab.com to add a section to their README.md, asking GitLab to support the community's effort to add federation :P - Do they need our help finding funding, so they can allocate a developer on their company to this? Probably not, they have their huge income already, but, who knows, let's help them if that's what it takes

👍 6

fr33domlover added the

Community

label 2022-09-29 06:53:40 +00:00

basxto commented

2024-04-19 02:25:31 +00:00

They don't seem excited about federation last time I checked, probably because their customers don't need/want it so there's no m0ney incentive in working on it

I do disagree with that, I see some use for (internal) company-run forges:

Companies do outsource projects or develop joint projects with others, for that they currently need to give guest accounts to employees of the other company. This could also be achieved with (partial) federation to selected instances and users. Employees don’t need to setup duplicate accounts on multiple instances.
When two companies merge, they can federate between their forges. Though defederating them on a split could be more troublesome?
Some companies abuse github as an issue tracker, forum and wiki for their products, but don’t do any commits. This could also achieved with partial federation, even though a private repo would not federate the actual code repo, it can federate the description, tags, wiki, (non-private) issues or even releases for freeware/freemium stuff. This would also have the benefit that they could automatically close issues with commits etc. The commits would then reference the commit they got closed with, but only users with repo access can see the actual commits. If releases would allow to make that distinction, normal users would only get access to stripped down demo versions and paying customers get access to the full releases, but still without getting access to the repo.
Companies who have an open source version and a proprietary pro version could reference issues and PRs of the OS version from the proprietary repo. That wouldn’t be publically visible, but would improve internal organization and connections between commits and issues and well as issues with related issues.
Extension of the previous point: if the OS version has delayed releases, commits of the pro version can mention and close issues in the OS version. But they would first only automatically get marked/tagged as fixed in the pro version and properly closed only when the commit updates come to the OS version. This might reduce manual steps need and also promote the other version.

This is not relevant for companies who have paid accounts on gitlab.com, but they also offer support for gitlab instances (Self Managed Premium & Ultimate) and gitlab SaaS (GitLab Dedicated). As well as selling them their new AI add-ons.

> They don't seem excited about federation last time I checked, probably because their customers don't need/want it so there's no m0ney incentive in working on it I do disagree with that, I see some use for (internal) company-run forges: * Companies do outsource projects or develop joint projects with others, for that they currently need to give guest accounts to employees of the other company. This could also be achieved with (partial) federation to selected instances and users. Employees don’t need to setup duplicate accounts on multiple instances. * When two companies merge, they can federate between their forges. Though defederating them on a split could be more troublesome? * Some companies abuse github as an issue tracker, forum and wiki for their products, but don’t do any commits. This could also achieved with partial federation, even though a private repo would not federate the actual code repo, it can federate the description, tags, wiki, (non-private) issues or even releases for freeware/freemium stuff. This would also have the benefit that they could automatically close issues with commits etc. The commits would then reference the commit they got closed with, but only users with repo access can see the actual commits. If releases would allow to make that distinction, normal users would only get access to stripped down demo versions and paying customers get access to the full releases, but still without getting access to the repo. * Companies who have an open source version and a proprietary pro version could reference issues and PRs of the OS version from the proprietary repo. That wouldn’t be publically visible, but would improve internal organization and connections between commits and issues and well as issues with related issues. * Extension of the previous point: if the OS version has delayed releases, commits of the pro version can mention and close issues in the OS version. But they would first only automatically get marked/tagged as fixed in the pro version and properly closed only when the commit updates come to the OS version. This might reduce manual steps need and also promote the other version. This is not relevant for companies who have paid accounts on gitlab.com, but they also offer support for gitlab instances (Self Managed Premium & Ultimate) and gitlab SaaS (GitLab Dedicated). As well as selling them their new AI add-ons.

Sign in to join this conversation.