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

81–90 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#81

Post by badrequest »

treyd wrote: post #76
meekins wrote: post #31

Earlier quoted context omitted.

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

It's approximately 0. Microsoft knew that GitHub had no moat being what it was when they acquired it. T hat's why they've been adding CI, Pages, Codespaces, Copilot, and a bunch of other crap that only some of which people actually asked for in order to raise switching costs. That would go against everything they've been doing the last couple years.

Pages predates Microsoft's acquisition, and I can use Copilot on the repos I commit to any other source control system.

Re: Gitlab's ActivityPub architecture blueprint

#82

Post by badrequest »

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 people making new tools instead of using the antiquated ones I'm familiar with?"

Re: Gitlab's ActivityPub architecture blueprint

#83

Post by sofixa »

globular-toast wrote: post #60
sofixa wrote: post #49

Earlier quoted context omitted.

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?

Wait, are you saying email is reinventing the wheel that is GitLab etc.? I think your history might be a bit backward here. My advice is to develop your own personal tools in such a way that you can handle all kinds of interactions with other developers and projects. It's pointless saying "I prefer this or that" when you probably don't get to make those decisions. Projects develop workflows and common tooling like fo…

> Wait, are you saying email is reinventing the wheel that is GitLab etc

Bolting a million custom tools around email to force it to do something it was never meant to do is reinventing the wheel, yes.

> Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.

Yes, and very very few of them prefer arcane workflows such as patches over email. Some highly critical ones like the Linux kernel do, but the vast vast vast majority of products use well oiled machines like GitHub, GitLab, Gogs, Gitea, etc.

Re: Gitlab's ActivityPub architecture blueprint

#85

Post by JoshTriplett »

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.

`gh pr checkout NNN` works very well to give a local copy for review, by pulling and checking out the PR branch. There are equivalent commands for gitlab.

Also:

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

Both PRs and emailed patches encourage reading and reviewing just the patch. With emailed patches, you need to prepare a local branch with the patches applied if you want to do the kind of review you describe; with a PR, you need to fetch and checkout the PR branch. I would argue that checking out the latter is substantially easier than the former, especially given the availability of command-line tools like `gh pr checkout`.

Re: Gitlab's ActivityPub architecture blueprint

#86

Post by radarsat1 »

alex_duf wrote: post #62
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

No, I mean a standard for the forge things like issues and comments and pull requests. The things that would be carried over activitypub here.

Re: Gitlab's ActivityPub architecture blueprint

#87

Post by konart »

treyd wrote: post #80
konart wrote: post #20

Earlier quoted context omitted.

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.

I think a lot of people get annoyed by email because they're used to using it in crappy web-based clients. In 2021 I switched back to using Thunderbird after many years using web gmail and my god it's a breath of fresh air. I'm not opposed to web based git Forges provided they're reasonably responsive and not sluggishly slow like GitLab has become.

I've used Outlook, Thunderbird, The Bat, Airmail, Spark and a few others I think.

Nothing beats not using email at all.

Fastmail has a good web client though. But what is more important it has aliases and "Masked email". They kind of make you life with email a bit more bearable.

Still - best email is dead email.

Re: Gitlab's ActivityPub architecture blueprint

#88

Post by konart »

funcDropShadow wrote: post #66
konart wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: Gitlab's ActivityPub architecture blueprint

#89

Post by ezst »

mariusor wrote: post #75
ezst wrote: post #61

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

As I replied to a sibling comment. I agree that I can review PRs on my local machine, which is sometimes what I do, but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :) > is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space. I disagree strongly with this type of sentiment. Mercurial…

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

> but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)

I don't follow, github gives it to you both ways, so I don't see the downside here. And on top of that, you can pull comments into your IDE of choice would you need to. I hardly see the problem, I suspect it isn't technical.

> I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist.

Your disagreement doesn't align with the reality, unfortunately. Could you name one mercurial forge? They aren't many left anymore, and you have to get out of your way to host your mercurial code somewhere. And while it's hard to name mercurial forge, it's easy to name high profile projects which reluctantly converted to git: python, mozilla, pypy. It only got worse over time, "interestingly", about as fast as git consolidated its monopoly. And that's the main flaw in your point, that success somehow is based on merit alone, with no influence of peer/social pressure/network effect.

FYI, I just submitted this post: https://news.ycombinator.com/item?id=39208464 which is pretty much what remains of hosted mercurial today.

Re: Gitlab's ActivityPub architecture blueprint

#90

Post by mariusor »

ezst wrote: post #89
mariusor wrote: post #75

Earlier quoted context omitted.

As I replied to a sibling comment. I agree that I can review PRs on my local machine, which is sometimes what I do, but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :) > is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space. I disagree strongly with this type of sentiment. Mercurial…

>> 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. > but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :) I don…

Sourcehut can host mercurial repositories.
Post reply on HN