@erlend I hope GitLab will manage to do everything they’re planning to join Fediverse. After that GitHub would need to hustle up do the same. I will help them with the roadmap:
@erlend@fediversenews@carl what a good idea, seems like a great next step for a git solution in general. The decentralisation open such possibilities. And got already support signed commits to ensure the commit is from the correct sender.
@erlend Even better move would be to participate in forgefed.org/. I didn't see any mention within their issues. Looks like #GitLab is trying to build ActivityPub support where it can't fulfill the need. Even while there already are efforts to build upon it and extend for a forge based protocol #ForgeFed. Leading to still isolated software instead of distributed where I don't need additional wrapper and efforts.
@danielsiepmann@fediversenews@erlend sorry, I should be clearer; as co-author of the AP and AS2 specs, I definitely think it makes a good fit for this use case, and I'm surprised by your assertion that it won't work.
@evan@danielsiepmann@fediversenews@erlend I think they don't realize ForgeFed is based on ActivityPub (although I think it doesn't use AS/2). So it's most definitely fulfilling that use case.
@erlend@evan as @blake wrote it is an extension to ActivityPub as activity pub fulfils some, but not all requirements. It doesn't know, and doesn't need to know, about patches, commits, issues, for example.
@danielsiepmann@fediversenews@erlend They're using ForgeFed logic as inspiration (it's mentioned in the epics by a GitLab developer in Brussels) but misspelled as fedForge
@erlend Now Gitlab will be in position to dictate standards, and this is probably a bad thing.
On the other hand, Gitea/Forgejo failed to implement federation despite working on it for years. Maybe Gitlab working on it will force them to reconsider their priorities and we'll finally see something usable.
#Git essentially has solved the distributed software development problem (at least the technical parts).
However, it has always bothered me that there is no generalization to distributed feedback in the form of issues and merge requests.
Several years ago, we've been playing with design ideas to have the issues also in git, but did like neither the models available then nor our own ideas. Finally a path forward! https://gitlab.com/groups/gitlab-org/-/epics/11247
@erlend@smallcircles@fediversenews Can you explain that end goal a bit more for the only partly technical like myself? Does that mean if a project is open to PR/MRs that anyone on AP anywhere can remotely send them an MR without having to log in to Gitlab and make the MR there?
A good site for background is https://forgefed.org where a specification for an AP extension is crafted. Implementers of the spec can exchange merge requests between code forge softwares. Another forge that has received @NGIZero funding to add federation support is Gitea. It's downstream fork Forgejo is also working on that.
On the Gitlab epic the question was asked whether @forgefed support is planned.
@Brendanjones the Why and How sections of that issue are highly instructive.
Your understanding seems correct: In the most expansive version of this vision, anyone running an AP-enabled git instance (with one or more repos) can send MRs to another instance’s repo, without having to sign up there.
For starters this will be GitLab-specific, but that’s already huge for self-hosters of GitLab who currently don’t benefit from the internal interop of the GitLab.com network.
@Brendanjones also hugely impactful as a way around GitHub’s moat as the de-facto social network of open source development. I follow hundreds of developers on GitHub, though mainly just to keep track of who I’ve interacted with, effectively adding them to a dev-specific address book.
I have a much harder time keeping track of non-GitHub devs on alt platforms, but if I could follow them on the fediverse that’s actually preferable over GitHub’s proprietary follow list.
Add comment