If you think that Linux can move to GitHub or GitLab and still be productive at scale, I want you to read through the MAINTAINERS file in the root of the Linux source tree.
Every one of those entries has a dedicated maintainer in charge of it, applying to a subset of the source tree. All 3,000 of them. Many of these have dedicated external trees, mailing lists, and policies. Almost all of this development happens away from the LKML. Each of those trees has a path upwards towards Linus's tree, often via other trees and other maintainers, or towards the -lts trees. These trees are not necessarily authoritative either, and the kernel you're running might be its own upstream maintained by your Linux distro, unique from any of the releases on kernel.org.
All of it is based on email. And it *works* to drive the most efficient and largest-scale open-source project in history.
@sir or complain that email is too hard for kernel maintainers born in the last decade, stolen are the skills to interact with mailing lists by fly by night startups lowering the barrier to entry and erecting walled gardens.
it's like boomers complaining that kids these days don't know how to build a fire or some shit, someone had to teach them instead of hiding it away like some super complicated system that they'll later need to depend on for their own survival.
@sir is there somewhere you’d point someone to start their study of the Linux development model?
@chip read MAINTAINERS, find some subsystems which interest you, and read through their mailing lists. Read some LKML and whatever Linus & Greg & <insert your favorite maintainer> are doing.
Great, thanks for the info @sir!
@sir i completely get why they do things this way, but accessibility with email is a huge problem for me, and it would be so overwhelming to participate in a project run like this that i never will. not that i'm at any huge chance of that happening these days.
@sir @frumble @forgefed I think email is simple and should be easy to learn, I just haven't had a lot of luck with my authors. They want Word. I managed them to use Gitlab's edit file and save since that is relatively close to that paradigm of open file/make change/save, but anything beyond that, they are lost.
Or, as my editor says, "I will not install a program just to work with you." :) I've tried for many years but not quite yet there yet. :P
@dmoonfire @frumble @forgefed git.sr.ht has this, see the video on this page: https://sourcehut.org/blog/2019-11-15-sourcehut-1-year-alpha/
No web editor nor plans to write one, though.
Sourcehut works fairly well for me (I only migrated 20 or so repos to try it out) but I also live in Git.
On the publishing side, it's a different beast because it is an uncommon use (automated publishing of books through Git) with a decidedly non-technical users (authors). But, I'm always interested in seeing if new things work better than what I have cobbled together. Always improve.
For most mailing lists you first have to subscribe before being able to send a single message at all, and then are getting all the message threads. No simple subscribing just to threads involving you, browsing old threads is hard as well.
I know you're working on better mailing list frontends and am excited how well they can solve these problems, but remain skeptical.
And yes, I am working on better mailing lists. But how is improving an existing system supposed to be a worse option than throwing everything out, starting from scratch, and shoehorning activitypub into the problem instead?
@sir @frumble The question here is what advantage the already existing e-mail infrastructure and ecosystem provides and what structural drawbacks the compatibility with legacy systems has.
In general I'm skeptical of starting fresh, but with @forgefed it should be okay as they're also using an existing open standard which already has gained some adoption in other areas.
-RT@reactorcontrol: Plaintext email for patches is like programming in a loosely typed language. Vastly underspecified and relies on undocumented conventions.
@sir It works*
*as long as you prevent the user from fucking up the brittle formatting, or any infrastructure components in between (mail client, mailman, …)
@schmittlauch just think of email as the transport. git send-email does the right thing. If we did it on ActivityPub then we'd have similar problems when someone drops a patch into their mastodon toot box.
And the MUA is the weakest link, mailman doesn't mangle patches and neither does anything else in the chain.
@sir Yeah, but nobody would be sending a patch via the Mastodon toot box, but using a more elaborated format just based on Activitypub.
Mastodon can the only use a kind of compatibility-representation.
I just mean, what are we throwing away when not being backwards-compatible with git-send-mail, and what are we gaining if doing so?
@schmittlauch I *like* using email. I like reviewing and responding to patches from my inbox. It works well with my workflow. I can easily filter and organize and manage my patches.
It's a distributed, fault tolerant, redundant system, none of which apply to ActivityPub.
Why are you so infatuated with ActivityPub that you have to reinvent every vaugely wheel-shaped object with it
@schmittlauch also, using activitypub would create a separate federation of patches from the existing email federation, which would not communicate with each other, whereas building better email tools allows you to stay connected with the established federation of mailing lists and maintainers using emails for patches.
There are dozens more reasons but every time I explain them it just goes in one ear and out the other. You've already decided that ActivityPub is right and email is wrong and there's nothing I can say to change that. I'm sick of rehashing this discussion.
@sir Great that it works for you, and I do support you building a system suiting your needs.
But apparently there's a large proportion of people for which it doesn't work, otherwise we wouldn't be talking about this.
Building on current git-send-email approach has the advantage of already working somehow and maybe being able to push the current limitations a bit further, trying to make it more comfy for folks with other work flows or setups.
Alternatively, a new backwards-incompatible forge federation format can be created on top of any transport, may it be e-mail, ActivityPub or whatever.
Advantage: Chance to design something more resilient with more features.
Disadvantage: possibility to fuck it up, re-inventing the (otimised) wheel
I currently like e-mail notificatios of my git forges for keeping track of PRs, issues etc. but then move over to the forge's UI for actual work, because it provides more features like milestones, labels, code highlighting.
When using ActivityPub in a semicompatible way, at least this mechanism can be taken care of by Mastodon et al.
@schmittlauch man, this is so bonkers to me. "The subway is aging and needs maintenance. Therefore we should extend shopping carts to handle moving large numbers of passengers throughout the city. Shopping carts work and have no legacy baggage."
@sir Holy shit Chrome chokes on this page...
@brandon works fine for me on qutebrowser (which is webengine based), though it takes a second to load.
Try the raw file:
@sir Raw file works fantastically, something is weird about the way chrome is sending the request, Firefox loads basically instantly
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!