Gitlab's ActivityPub architecture blueprint
docs.gitlab.com
Gitlab's ActivityPub architecture blueprint
1–10 of 107 posts
Re: Gitlab's ActivityPub architecture blueprint
#2What's really strange is ForgeFed, Forgejo, Gitea, etc. have all been working on this for a while with a goal to be interoperable, and GitLab doesn't mention any of that at all. Are they planning to enter this late and build a completely incompatible solution?
Re: Gitlab's ActivityPub architecture blueprint
#3Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous.
Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Re: Gitlab's ActivityPub architecture blueprint
#4What's really strange is ForgeFed, Forgejo, Gitea, etc. have all been working on this for a while with a goal to be interoperable, and GitLab doesn't mention any of that at all. Are they planning to enter this late and build a completely incompatible solution?
Don't suppose you have links to the work they have been doing towards this?
Re: Gitlab's ActivityPub architecture blueprint
#5What's really strange is ForgeFed, Forgejo, Gitea, etc. have all been working on this for a while with a goal to be interoperable, and GitLab doesn't mention any of that at all. Are they planning to enter this late and build a completely incompatible solution?
Don't suppose you have links to the work they have been doing towards this?
Of course: https://forgefed.org/
Re: Gitlab's ActivityPub architecture blueprint
#6Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Because people don't know about https://sr.ht
Re: Gitlab's ActivityPub architecture blueprint
#7Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Because people don't know about https://sr.ht
I'm intrigued, can you elaborate?
Re: Gitlab's ActivityPub architecture blueprint
#8Earlier quoted context omitted.
Don't suppose you have links to the work they have been doing towards this?
Of course: https://forgefed.org/
:facepalm: I thought they were all names of alternative source control projects, didn't realise the first one was the name of the collaboration effort.
Thank you :-)
Re: Gitlab's ActivityPub architecture blueprint
#9Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Enabling devs to be "social" in their way is a good trend.
Re: Gitlab's ActivityPub architecture blueprint
#10What's really strange is ForgeFed, Forgejo, Gitea, etc. have all been working on this for a while with a goal to be interoperable, and GitLab doesn't mention any of that at all. Are they planning to enter this late and build a completely incompatible solution?
It sounds like they have heard of it and plan to support it once they get to that point of their implementation.
There is some discussion in there epic tracking the feature - https://gitlab.com/groups/gitlab-org/-/epics/11247