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

101–107 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#101

Post by funcDropShadow »

orangeboats wrote: post #71
funcDropShadow wrote: post #65

Earlier quoted context omitted.

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

>Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate If that were the case we wouldn't have had this discussion today. Email workflow is abysmal and the limited innovations it has (patchwork comes to mind) is not enough to attract new developers. What's worse is that the email workflow is very resistant to changes[0], and arguably, the people supporting the…

> Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata.

Emails do have header, there is no problem storing metadata in those.

Re: Gitlab's ActivityPub architecture blueprint

#102

Post by orangeboats »

funcDropShadow wrote: post #101
orangeboats wrote: post #71

Earlier quoted context omitted.

>Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate If that were the case we wouldn't have had this discussion today. Email workflow is abysmal and the limited innovations it has (patchwork comes to mind) is not enough to attract new developers. What's worse is that the email workflow is very resistant to changes[0], and arguably, the people supporting the…

> Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata. Emails do have header, there is no problem storing metadata in those.

"Metadata" here refers to everything surrounding the git repo, e.g. CI status, milestones, or even reactions. Those metadata are constantly updated and since there are no mechanisms to retroactively update previous emails to include the new metadata, the only way to do it is to send even more emails to the already-voluminous mailing list to keep the email-only people updated.

This is why I have serious doubts on the possibility to build forges (with accessibility and feature set on par with GitHub/GitLab) on top of emails. And please, don't use the minimalism excuse because those extra features of forges _are_ being used. Removing them for the sake of forge-on-email is a strict UX degradation and you only end up making both forge people and email people angry.

Another way to share those metadata through emails is to send an email that links to an external HTTP website which displays the latest updated data, as is done by some projects for CI. But at that point, it ceases to be an "email workflow" in my opinion -- if you are already hosting a HTTP server, you might as well host a git forge on it.

Re: Gitlab's ActivityPub architecture blueprint

#103

Post by orangeboats »

funcDropShadow wrote: post #100
konart wrote: post #88

Earlier quoted context omitted.

Not every thing needs customization. Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process. Neither applies to email in my opinion.

But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.

That email clients is the way they are by default, should already say something, no?

The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad.

It's possible that you can fix a car with just a knife. But considering the difficulties and how unintuitive it is - is that not a sign of knife being somehow bad for the job?

Re: Gitlab's ActivityPub architecture blueprint

#104

Post by sdht0 »

mariusor wrote: post #74
madeofpalk wrote: post #58

Earlier quoted context omitted.

> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it? For what it's worth, you can just add .patch onto the end of a github PR URL to get that.

I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context. I can of course do the same with the PR, but then it loses its convenience. :)

> I can of course do the same with the PR, but then it loses its convenience. :)

Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.

Re: Gitlab's ActivityPub architecture blueprint

#105

Post by funcDropShadow »

orangeboats wrote: post #103
funcDropShadow wrote: post #100

Earlier quoted context omitted.

But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.

That email clients is the way they are by default, should already say something, no? The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad…

> Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad.

No, email is better suited for meaningful communication than most forums and code review web interfaces. And that is a direct consequence of the fact that it was designed to facilitate communication between humans. Github is simply missing a way to see easily and intuitively which message responded which other. I am thinking of something like the classic threading tree of an email client. That information makes it much easier to follow a discussion between more than two people.

That same tree is also great at showing what I have already read and what is new. How do you do that in GitHub? As far as I know there is no way to do that. I can even label certain messages just for me. In order to keep the overview. I can move emails between folders virtual or not to organize all the communication threads that I am participating in. Neither of which is possible with pull requests in GitHub or almost every other forge.

Re: Gitlab's ActivityPub architecture blueprint

#106

Post by funcDropShadow »

orangeboats wrote: post #102
funcDropShadow wrote: post #101

Earlier quoted context omitted.

> Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata. Emails do have header, there is no problem storing metadata in those.

"Metadata" here refers to everything surrounding the git repo, e.g. CI status, milestones, or even reactions. Those metadata are constantly updated and since there are no mechanisms to retroactively update previous emails to include the new metadata, the only way to do it is to send even more emails to the already-voluminous mailing list to keep the email-only people updated. This is why I have serious doubts on the…

You bring up valid points. I am not at all arguing we should strive for minimalism and reduce features that are actually used. If we are already using html emails for everything, why can't we embed the little build status widgets, plugins, tags -- whatever they are called -- that you find in many readme file on Github into html emails?

Or it is great idea to have a plugin for your mail program showing the build status of your ci plugin next to the email about the pull/merge request?

Re: Gitlab's ActivityPub architecture blueprint

#107

Post by konart »

funcDropShadow wrote: post #100
konart wrote: post #88

Earlier quoted context omitted.

Not every thing needs customization. Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process. Neither applies to email in my opinion.

But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.

Okay, but what other choice do I have? Neuralink?
Post reply on HN