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

91–100 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#91

Post by avgcorrection »

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’ve used email a bit and there are some pros and cons.

For email: It’s just there already, like you mention. Once you are setup you can do things like comment on a “line of code” very straightforwardly. It’s already distributed and all that. There are bespoke (project-specific probably) bridges from forges (maybe mostly GitHub) to mailing lists.

For this new thing: You don’t have to worry about all the legacy of email. You don’t have to worry about 90% of the world using email “wrong” according to techies. You can probably track changes more easily than keeping track of where you sent patches. You don’t have to make bespoke forge-to-email bridges.

Re: Gitlab's ActivityPub architecture blueprint

#92

Post by avgcorrection »

ezst wrote: post #61
mariusor wrote: post #46

Earlier quoted context omitted.

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

You can still get a “diff of diffs” with git range-diff. (If I interpret you correctly.) Like it says that in this iteration a paragraph was added to one commit, another commit was dropped, and another commit was expanded.

But you gotta do most of the work of lining up what the previous thing was yourself. (Inconvenient if you rebased and can’t seem to find the previous version.)

Re: Gitlab's ActivityPub architecture blueprint

#93

Post by avgcorrection »

JoshTriplett wrote: post #85
mariusor wrote: post #46

Earlier quoted context omitted.

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…

Others keep in mind that Josh is so experienced with the email workflow that he made a tool to manage multiple versions of a “patch series”: git-series

(git(1) doesn’t help you with maintaining patch series)

Re: Gitlab's ActivityPub architecture blueprint

#94

Post by paulddraper »

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.

> Microsoft knew that GitHub had no moat

GitHub had the best moat: network.

But yes, the additions have only deepened it.

Re: Gitlab's ActivityPub architecture blueprint

#95

Post by avgcorrection »

argulane wrote: post #36
aloisdg wrote: post #29

Earlier quoted context omitted.

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

E-mail based workflow for Linux is starting to break down as the amount of patches is too huge. * https://lwn.net/Articles/860607/ * https://lwn.net/Articles/952034/ * https://lwn.net/Articles/952146/ * https://lwn.net/Articles/950567/ * https://lwn.net/Articles/959069/ * https://lwn.net/Articles/815332/

Very interesting, thanks for sharing. It’s nice to see a side of this which isn’t just about a clash of tech cultures (it seems).

Re: Gitlab's ActivityPub architecture blueprint

#96

Post by JoshTriplett »

avgcorrection wrote: post #93
JoshTriplett wrote: post #85

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

Others keep in mind that Josh is so experienced with the email workflow that he made a tool to manage multiple versions of a “patch series”: git-series (git(1) doesn’t help you with maintaining patch series)

Thank you, you just made my day. (I feel bad about leaving that undermaintained, though.)

Re: Gitlab's ActivityPub architecture blueprint

#97

Post by ubertaco »

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…

I would love this. I created a Codeberg account to contribute to an OSS Android app I liked. Then, (thankfully, after my contribution was merged) I had a situation where I lost access to my 2fa codes. I could provide other identity verification, but where? Their official docs tell you there's a support at Codeberg email address....but that nobody looks at that inbox. They link a Discord room (kinda defeats the appeal of an EU-hosted indie forge, but okay). I went in there, and was told (eventually, when the apparently sole employee in the room) that I was out of luck. Not because they couldn't verify my identity or anything, but because support for account-related issues is something they categorically do not offer.

I'd love to regain the ability to contribute to stuff that is trapped in the Codeberg ice without having to create another account on a service with that sort of ramshackle operating approach.

Re: Gitlab's ActivityPub architecture blueprint

#98

Post by ezst »

avgcorrection wrote: post #92
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+…

You can still get a “diff of diffs” with git range-diff. (If I interpret you correctly.) Like it says that in this iteration a paragraph was added to one commit, another commit was dropped, and another commit was expanded. But you gotta do most of the work of lining up what the previous thing was yourself. (Inconvenient if you rebased and can’t seem to find the previous version.)

Mercurial's evolve is more about tracking history rewrites and their context. If I submit a series of commits, and over the review you have me amend one mid-series, then rebase few identically on top of that, then add some new changes, and split some existing ones, mercurial will still know how every single commit in the resulting series relates to things from the original PR. As such, answering questions like "show me how commit 3 was updated several times over multiple series submissions" is trivial.

Re: Gitlab's ActivityPub architecture blueprint

#99

Post by radarsat1 »

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've wondered if there might be room for services that use email as their communication channel. Something like this would be perfect for it. The forges would send emails to communicate in issues, information is distributed via mailing lists, but forges parse and display the information in their own way. They become fancy single-purpose email clients basically.

With such a system, people could also contribute by writing the same emails by hand, as long as the format remains accessible. And no special protocols necessary, all existing mailing list infrastructure can be used instead of designing new complicated ways of doing the same thing.

Re: Gitlab's ActivityPub architecture blueprint

#100

Post by funcDropShadow »

konart wrote: post #88
funcDropShadow wrote: post #66

Earlier quoted context omitted.

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.

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.
Post reply on HN