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

21–30 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#21

Post by bmacho »

orangeboats wrote: post #19
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

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…

> (1) It's hard to track the development of a patch in mailing lists unless you actively follow it.

I would add that if you automatize it somehow, then you don't "just use e-mail", but you have a different protocol for it (over email in this case).

Re: Gitlab's ActivityPub architecture blueprint

#22

Post by emaro »

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.

Re: Gitlab's ActivityPub architecture blueprint

#23

Post by LudwigNagasena »

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.

Re: Gitlab's ActivityPub architecture blueprint

#24

Post by rvense »

wielebny wrote: post #11

This is exciting and could be disruptive to closed software hosting platforms. ActivityPub's open standard is an added bonus. A fediverse for code? Sing me in.

Yes, my first thought is - doesn't this allow other sites to interoperate with Gitlab without asking Gitlab? Like Gitea can implement this and now we can do PRs back and forth? That's fantastic, exactly what the internet is for and the sort of thing we need more of.

edit - learned about https://forgefed.org/ from a sibling thread, great stuff.

Re: Gitlab's ActivityPub architecture blueprint

#25

Post by LudwigNagasena »

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 would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.

Re: Gitlab's ActivityPub architecture blueprint

#26

Post by joshxyz »

crotchfire wrote: post #6
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

Because people don't know about https://sr.ht

does sourcehut support shat gitlab is trying to achieve here?

Re: Gitlab's ActivityPub architecture blueprint

#27

Post by globular-toast »

orangeboats wrote: post #19
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

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? We already use a ton of other tools specific to software development.

A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically.

Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.

Re: Gitlab's ActivityPub architecture blueprint

#28

Post by Hendrikto »

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

You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?

Re: Gitlab's ActivityPub architecture blueprint

#29

Post by aloisdg »

Hendrikto wrote: post #28
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

You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?

Do you have a source for that? I would like to learn more about that

Re: Gitlab's ActivityPub architecture blueprint

#30

Post by edent »

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 having to sign up to yet another service.

Very excited to see how this pans out.

Post reply on HN