Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab's ActivityPub architecture blueprint

docs.gitlab.com

Post reply on HN
Print view View original

41–50 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#41

Post by mariusor »

xyzzy_plugh wrote: post #3

Contemplating 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

> why are we like this

It's not clear about what you're complaining here. What exactly is ridiculous?

This just offers a different channel through which to circulate patches. Unlike email, which requires everyone follow some ad-hoc convention in the email message, with ActivityPub the protocol itself can support structured data about the patch.

Re: Gitlab's ActivityPub architecture blueprint

#42

Post by mariusor »

kodama-lens wrote: post #12

Okay, let's think this a little further: I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing. It would just have the time of creating an external user on my instance (or pa…

ActivityPub supports authorized requests from federated actors, which would allow access to private resources. It would be a trivial exercise (speaking here as someone that implements fediverse software) to add permissions for users on other gitlab instances.

Re: Gitlab's ActivityPub architecture blueprint

#43

Post by imiric »

LudwigNagasena wrote: post #23
xyzzy_plugh wrote: post #3

Contemplating 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

But why do you need email if git is already built for decentralized communication? That's the core of the problem. Just add the ability to ask for pull requests, to comment, etc into git and nobody will build those insane protocol-on-top-of-a-protocol-to-communicate-with-a-side-protocol monstrosities.

git-appraise[1] implements that concept. From Google, no less.

I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did.

[1]: https://github.com/google/git-appraise

Re: Gitlab's ActivityPub architecture blueprint

#44

Post by ragebol »

meekins wrote: post #31
edent wrote: post #30

This is fantastic. I stick my personal projects on GitLab and Codeberg - but if I want people to contribute, I use GitHub; that's where the people are. GitHub has a number of weird repos from popular projects which are just copies of other repos. You can look, but you can't touch. (WordPress and Linux are the big ones). It would be brilliant to look at a project in my preferred UI and raise issues / PRs without havin…

It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?

Only when there is so much critical mass behind all of it's competitors that they can't ignore it any longer. Improbably, for the time being.

I was going to say that Microsoft has no social network, so that this might open them up etc, but then again, there's LinkedIn.

Re: Gitlab's ActivityPub architecture blueprint

#45

Post by manfre »

emaro wrote: post #22
kodama-lens wrote: post #12

Okay, let's think this a little further: I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing. It would just have the time of creating an external user on my instance (or pa…

Sharing of private resources is explicitly stated as a non-goal.

Does ActivityPub even support interactions that are actually private? Last time I worked with it, the private messaging was more akin to "please don't read this postcard" in the mailbox.

Re: Gitlab's ActivityPub architecture blueprint

#46

Post by mariusor »

JoshTriplett wrote: post #18
alufers wrote: post #13

Earlier quoted context omitted.

For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR. Same for reviewing, each comment can be replied…

> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is b…

I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way.

So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code.

I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.

The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.

Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.

Re: Gitlab's ActivityPub architecture blueprint

#47

Post by rglullis »

meekins wrote: post #31
edent wrote: post #30

This is fantastic. I stick my personal projects on GitLab and Codeberg - but if I want people to contribute, I use GitHub; that's where the people are. GitHub has a number of weird repos from popular projects which are just copies of other repos. You can look, but you can't touch. (WordPress and Linux are the big ones). It would be brilliant to look at a project in my preferred UI and raise issues / PRs without havin…

It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?

Not the best way to look at it. A lot of developers today work primarily on github because it's not possible to interact/work in other projects from their siloed forges. When gitlab implements AP, things are no longer siloed and therefore there will be a percentage of (current) Github users who will free to choose their forge independently of network effects.

It's better to ask "how many projects are stuck to Github exclusively because of collaboration tools, and how many of these would be able to leave Github once more Gitlab/Gitea/Forgejo are able to interoperate? How much of its customer base can Github afford to lose before being forced to give up their monopolistic strategy?"

Re: Gitlab's ActivityPub architecture blueprint

#48

Post by orangeboats »

globular-toast wrote: post #27
orangeboats wrote: post #19

Earlier quoted context omitted.

I like the user experience of forges far more than email clients. (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads. And god forbid people changing subject line…

A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development?…

>tooling

I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this.

And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?

>Conventions are good. It's part of being human.

It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling.

I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us.

Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.

Re: Gitlab's ActivityPub architecture blueprint

#49

Post by sofixa »

globular-toast wrote: post #27
orangeboats wrote: post #19

Earlier quoted context omitted.

I like the user experience of forges far more than email clients. (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads. And god forbid people changing subject line…

A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development?…

So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close?

Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?

Re: Gitlab's ActivityPub architecture blueprint

#50

Post by grey_earthling »

> People want a single, global GitLab network

This sounds like they're trying to make a proprietary GitLab-only alternative to Forgefed. I don't understand who would want this.

Edit:

Ah, this sounds like the opposite: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529...

Good!

Post reply on HN