Gitlab's ActivityPub architecture blueprint

Post by meekins » Wed, Jan 31, 2024, 11:13 AM UTC

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…

Post by Hendrikto » Wed, Jan 31, 2024, 11:15 AM UTC

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?…

Post by Hendrikto » Wed, Jan 31, 2024, 11:18 AM UTC

aloisdg wrote: post #29

Hendrikto wrote: post #28

Earlier quoted context omitted.

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

Post by argulane » Wed, Jan 31, 2024, 11:37 AM UTC

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?…

Post by argulane » Wed, Jan 31, 2024, 11:41 AM UTC

alufers wrote: post #13

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

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…