This is exciting and could be disruptive to closed software hosting platforms.
ActivityPub's open standard is an added bonus. A fediverse for code? Sing me in.
Gitlab's ActivityPub architecture blueprint
11–20 of 107 posts
Re: Gitlab's ActivityPub architecture blueprint
#12Okay, let's think this a little further:
I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing.
It would just have the time of creating an external user on my instance (or paying premium for them). Buth this could also be archived via OIDC logins of specific allowed accounts.
Am I missing the advantages here?
Re: Gitlab's ActivityPub architecture blueprint
#13Contemplating 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 to separately or resolved, which serves as a nice TODO list for the original author.
I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward.
Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.
Re: Gitlab's ActivityPub architecture blueprint
#14Contemplating 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
> simply using email and git (ala Linux) to share, review and consume patches
yeah, but when was the last time any of us did that...?
Re: Gitlab's ActivityPub architecture blueprint
#15Does GitLab have an existing Fediverse presence, for example on a Mastodon instance?
Re: Gitlab's ActivityPub architecture blueprint
#16Contemplating 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…
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.
Re: Gitlab's ActivityPub architecture blueprint
#17Contemplating 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
> Contemplating this through the lens of simply using floppy disks and FedEx (ala Real Actual Serious Programming) 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 an email with a patch to another user instantly, but... why are we like this
Re: Gitlab's ActivityPub architecture blueprint
#18Contemplating 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…
> 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 baroque, painful both to send and to receive, lacking in features, and error-prone.
Re: Gitlab's ActivityPub architecture blueprint
#19Contemplating 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 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 lines thus breaking the thread.
Meanwhile, discussions in forge workflow tend to be concentrated in the same merge request or issue.
(2) Discovering patches is also a fairly difficult thing to do in mailing lists. The forges include tools like issue trackers and in each issue there is a list of all mentioned merge requests, and the status of those MRs (whether open, closed or merged) are immediately obvious.
(3) I also like labels for similar reasons as (2) - don't get me wrong, I know email subjects often start with "some sort of tag:", but labels are sometimes used to mean "hey, this $MODULE1 code isn't directly related to $MODULE2, but might have some interactions with it so you should take a look". Cc-ing is a manual process which is annoying and like many manual processes is subject to human errors.
(4) Emails rely heavily on conventions, e.g. should people top-post or bottom-post or inline-reply? That introduces a barrier of entry.
As a sidenote, personally I hate that I occasionally have to scroll through long, long, emails that include reply chains from eons ago, but there's nothing email can really do to prevent it from happening. It's conventions all the way down.
Re: Gitlab's ActivityPub architecture blueprint
#20Contemplating 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.