This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".
https://gitlab.com/groups/gitlab-org/-/epics/11247#note_2597450590
Sometimes it really does help if a lot of people comment. The #ActivityPub issue was reopened by #Gitlab:
https://gitlab.com/groups/gitlab-org/-/epics/11247#note_2603598572
(1/2)
@claudius
> Gitlab just closed the issue about supporting ActivityPub
They don't want to be leaders, they'd rather be followers (or worse, also-rans). Fine, we can work around them.
ForgeFed support for GL could be built as a plugin or a patch, based on any AP code @kik published so far, and adopted by independent GL instances. Once a critical threshold of adoption is reached, the network effects will be large enough that the GL flagship will follow.
(2/2)
It would be a great project for a grant application. Especially if a bunch of GL instance admins were willing to commit to using a working FF implementation, and lay out a rough plan for sharing the load of ongoing maintenance of the code.
Even better if a group of devs pick a code forge each, and apply for grants for a FF plugin/ patch for it, with support from some instance admins;
https://wiki.p2pfoundation.net/List_of_Community-Hosted_Code_Forge_Instances
The network effects of all that would surely be convincing to grant-makers.
**But** it's still an idea worth considering, I think, in retrospect. 😅 Because it would allow to bypass completely the major pain point of contributing to GitLab: being forced to send very small MR, just a few lines at a time, and having to explain again and again to new people reviewing it what the whole point is about and how you're doing it, which causes each small MR to take weeks to merge, and then you have 4 or 5 more to merge because you had to split your feature. For something like ActivityPub that is made of many features, being able to develop the support independantly without this grind would certainly help.
I imagine the work would go much faster, be more exciting (coz faster), and more fun (coz faster and exciting). Maybe easier to get more devs helping too?
Re: getting it all merged, it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a time : P
I'd be happy to help recruit a few GL instances admins as testers. Here's some candidates;
https://wiki.p2pfoundation.net/List_of_Community-Hosted_Code_Forge_Instances
> Re: getting it all merged, it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a time : P
wouldn't it? 😊 Of course, I'm not the one who decided to split everything in many MR. If you try to merge something big, GitLab will reject the MR, asking you to split it into smaller chunks. Because they take reviewing very seriously, each line is scrutinized and has to be perfectly understood by the reviewer.
There are very good reasons for that too. GitLab is used by governments and fortune 500 companies, they have to adhere to certifications, and they can't just YOLO merge randos' code.
(1/2)
@kik brevity trumps clarity once again : P Sorry about that. When I said;
> it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a time
What I meant was, if they see the whole thing working between independent GL instances, they may grok it in a way they currently don't. If so, they'd be more motivated to prioritise all the MRs required to integrate it, and maybe put an employee on shepherding the whole lot through efficiently.
Could be the puzzle piece you’re looking for.
A space for Bonfire maintainers and contributors to communicate
