A mail based development workflow already is federated

Discussions
#1

Bonjour,

There is a recurring argument made against the efforts to federate forges, for instance today on HN:

Maybe cooperability is already a solved problem? As I understand, Linux kernel changes are managed entirely by text-only email, and email is of course entirely forge-agnostic.

I was never comfortable replying because this is true but leads to the wrong conclusion in a subtle way. Only today was I able to articulate why:

Yes, it is solved in this particular context: Linux kernel, Qemu and all Free Software projects that have a mail based workflow. But there are other contexts where Free Software developers chose a different workflow such as using a forge. Whatever the reasons, this is where we are now. There are two paths forward: a) convince people using forges to switch to a mail based workflow, b) federate forges. I believe SourceHut and many other do a fine job trying to convince people to switch to a mail based workflow. The https://forgefriends.org and https://gitea.io projects chose to try to federate forges. It’s not a competition, there is value in both approaches and they will apparently move forward in parallel for the foreseeable future.

Do people think this is a valid answer? Or is there a better one?

#2
#3

I largely agree with the email workflow solving federation problems but here are my two cents:

SMTP is exclusive while HTTP is universal: Some ISPs don’t allow traffic on port 25 and even if they did, mail servers from popular services like Google don’t process emails from servers running in residential IP addresses. It’s one of the reasons why I don’t have a self-hosted email server.

So if the email-based workflow is the only workflow available, then folks like me will have no choice but to depend on a service provider.

Merge/Pull requests come with GPG-signed commits:
I’m not sure why GPG signed commits are not emphasized in email-based workflows. Signing is offloaded to emails but when git supports having signed commits, why settle for an external verification mechanism?

1 Like
#4

I see it like this… if you have a CLI, why do you nee a UI, right? Why did Windows follow from MS-DOS? Forges vs. mail-based workflows are completely different user experiences. Your last sentence says it best: different approaches, different tastes. For each their own.

For me a forge offers significant advantage over mail-based workflows. I hate the UX of email, with large inboxes, and mails all over the place, out of contexts, unordered. Sure you can bring order, but it is a chore. But forges offer way more. They have whole lists of features in their UI layouts, and all of them provide value to me in working in code projects in an organized manner.

But it is pure personal preference. If you love mail, love CLI and are proficient with it, then it can be very powerful. For some people a UI works best, for others it doesn’t. Some prefer vim, others a richer word processor. I think Sourcehut can be a very effective tool as well, but for me a UI works best and Gitea has greater appeal.

1 Like
#5