@strypey it's not a merging priority issue, it's just as slow to merge their own MRs made by their developers. GitLab is a really big machine with hundreds of full time developers adding code to it constantly (if you want to be amazed, go look at the commit history of their main branch and reload it multiple times - well, not on Sunday, though 😅), they have to keep it in check. I'm tempted to say the slowness is a feature more than a bug, for them.

I'm all for the idea of having this kind of features as a plugin, should GitLab develop plugin support, but hoping we could bruteforce the all code at once back into the main codebase when the features are complete because they would find it cool is not realistic, I think (they're already very aware of how cool it is). That would be bruteforcing thousands of lines of code in, and I would think that would be an infraction to the ISO norms they have to adhere to. If it's a plugin, it stays a plugin.

@strypey

> 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.

@strypey I don't think GitLab has plugin support, to my knowledge, so it would have to be a patchset, with the obvious usal problem of having to fix breakages happening because upstream doesn't know the code exists, and the other usual problem of explaining to users how to patch their vanilla GitLab, or having to distribute a patched version.

**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.