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

61–70 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#61

Post by ezst »

mariusor wrote: post #46
JoshTriplett wrote: post #18

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

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

FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want.

I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that.

At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.

Re: Gitlab's ActivityPub architecture blueprint

#62

Post by alex_duf »

radarsat1 wrote: post #51

A tool that automatically scraped github issues etc into a standard format and committed them to the repo could accomplish the same thing, no activitypub needed! Then collaborating peer forges could clone the info straight from git and submit changes etc. I think git already has all the sharing tools necessary, what is needed is standards and converters.

>what is needed is standards and converters.

You mean a standard like activitypub? /s

Re: Gitlab's ActivityPub architecture blueprint

#63

Post by themk »

joshxyz wrote: post #26
crotchfire wrote: post #6

Earlier quoted context omitted.

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

does sourcehut support shat gitlab is trying to achieve here?

Does sr.ht support cross instance patches? Yes. Even better, you don't even need an account on any sr.ht instance to send a patch, or receive one for that matter.

It's just email. And it can do many of the things other forges do. Trigger builds, comment on patches, track issues, etc.

Re: Gitlab's ActivityPub architecture blueprint

#64

Post by couchand »

myaccountonhn wrote: post #55
bmacho wrote: post #21

Earlier quoted context omitted.

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

I think the beauty of email is that it's already an open, federated standard. Is it easier to build this new activitypub layer on top of all forges, or is it easier to build a decent tool on top of email?

The answer to that question depends on where "the mindshare" is, and unfortunately we're living in a future where many seem to believe the former is easy and the latter impossible.

Re: Gitlab's ActivityPub architecture blueprint

#65

Post by funcDropShadow »

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

Earlier quoted context omitted.

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

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

It would be better if the user could actually select his tool instead of being forced upon a tool by a project or company. The former used to be the standard with email. Today, I have the impression half of my colleagues never used a mail program that wasn't called Outlook or Gmail. Spoiler alert: Both are abysmal mail readers for the purpose of following and participating in technical discussions. To fix that, they should at least support proper threading and encourage selective inline replies.

Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate. As long as Outlook-ordering decisions are made at the C* level it will never support software developers properly.

Re: Gitlab's ActivityPub architecture blueprint

#66

Post by funcDropShadow »

konart wrote: post #20
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

Last thing I want in my workflow is fucking email. I understand that for some people digging through their email (and mailing lists archives) is fun but this is just a tiny minority.

The difference is, I can customize my mail reader to my preferences. I can use macros to streamline my repetitive work with it. Neither is easily done with forges.

Re: Gitlab's ActivityPub architecture blueprint

#67

Post by wiktor-k »

manfre wrote: post #45
emaro wrote: post #22

Earlier quoted context omitted.

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.

I guess it depends on your definition of privacy but if you're thinking about end-to-end encryption then there's nothing like that in ActivityPub. Admins of the receiver and the sender can see all messages including direct messages. They are not visible to the broader public though.

Re: Gitlab's ActivityPub architecture blueprint

#68

Post by xyzzy_plugh »

madeofpalk wrote: post #16
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…

The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.

Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.

Re: Gitlab's ActivityPub architecture blueprint

#69

Post by xyzzy_plugh »

myaccountonhn wrote: post #55
bmacho wrote: post #21

Earlier quoted context omitted.

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

I think the beauty of email is that it's already an open, federated standard. Is it easier to build this new activitypub layer on top of all forges, or is it easier to build a decent tool on top of email?

It would be nice if it were the latter but given the stranglehold the major email providers have over email I think it's a lost cause.

Just look at the hoops you have to go through to send a patch over gmail.

Re: Gitlab's ActivityPub architecture blueprint

#70

Post by xyzzy_plugh »

imiric wrote: post #43
LudwigNagasena wrote: post #23

Earlier quoted context omitted.

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

Similarly Gerrit stores everything, including permissions, in Git as well. I'm not sure there is an offline review flow yet, though, but it's certainly possible.
Post reply on HN