Follow

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.

git.sr.ht/~sircmpwn/linux/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.

You should study the Linux development model if you truly want to grasp the profound ways in which git is a *distributed* version control system.

LMKL is famously one of the busiest mailing lists on the internet, clocking in at as much as 1,000 emails per day

And *most* Linux development happens on other mailing lists.

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

@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 But don’t you think it would possibly be a good idea to make collaboration easier and 21th century? There might be a better federated approach which could still deliver additional value over mailinglists.

Take a look at @forgefed, that’s the direction to go I see here.

@frumble @forgefed no, I don't think so. I also HATE this sentiment that OLD == BAD, implied by your "more 21st century". Email works, it's easy, it's effective, it's decentralized, it's based on open protocols, and it can be made to work with the GitHub-style noob-handholding UX.

@frumble @forgefed I was an early participant in the forgefed design discussions and we went our separate ways because they are infatuated with ActivityPub and have no eyes for the working, standardized, federated protocol which is email

@sir @frumble @forgefed activitypub is at least sort of acceptable federated protocol

@sir @frumble @forgefed Finding the bridge between the web UI and patch emails is the thing I'm most interested in. Most of my contributors are non-technical so I need the handholding for them otherwise they just send me word documents and tell me to make the change. 🙂

@dmoonfire @frumble @forgefed this is what sourcehut aims to achieve. But I also believe that no one is unable to learn new things, and I believe that learning email is not an unbroachable burden for anyone, not by any stretch of the imagination

@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

@sir @frumble @forgefed Seeing a third party project that does the web UI thing would be awesome, something that would format as a patch, but I haven't found anything I like there yet either. :(

@dmoonfire @frumble @forgefed git.sr.ht has this, see the video on this page: sourcehut.org/blog/2019-11-15-

No web editor nor plans to write one, though.

@sir @frumble @forgefed I would never ask for a web editor. :) Do one thing well.

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.

@sir @frumble @forgefed Email, at least in its current form, does *not* work well for onboarding:

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.

@schmittlauch @frumble @forgefed this is true for *some* mailing lists - a significant minority, but not most. The culture is changing. I agree that this is annoying, though.

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.

@sir
:birdsite:-RT@reactorcontrol: Plaintext email for patches is like programming in a loosely typed language. Vastly underspecified and relies on undocumented conventions.
twitter.com/reactorcontrol/sta
@frumble

@sir Obviously it is possible to define a better format by including new header fields instead of trying to specifiy everyithing in the non-typed plaintext message body, but then you can also do this as JSON-LD extensions like @forgefed does.
@frumble

@schmittlauch @frumble this has been brought up before but fails to account for the fact that it, you know, works

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

->

@sir
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

@sir
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."

@brandon works fine for me on qutebrowser (which is webengine based), though it takes a second to load.

Try the raw file:

git.sr.ht/~sircmpwn/linux/blob

@sir Raw file works fantastically, something is weird about the way chrome is sending the request, Firefox loads basically instantly

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!