I think having everyone see all the emails is part of the point. Even with self-hosted Gitea, someone has to _host_ it. And there isn't a trivial export button, and if the host goes rogue they can make it inaccessible and make everyone lose efficiency while they swap back to the old method.

And if you need email to authenticate on a website, why not just use email anyway?

But this is an interesting idea, and I'm on the look-out for ideas to replace email. I'll keep "LKML" in the back of my head as a use case.

>And there isn't a trivial export button

It does support making backups of repositories at least.

>and if the host goes rogue they can make it inaccessible and make everyone lose efficiency while they swap back to the old method.

Isn't this also a problem if the person managing the email list goes rogue? You have to trust someone to host the infrastructure.

>And if you need email to authenticate on a website, why not just use email anyway?

Because Email may not be the optimal user interface for handling issues, pull requests, code review, etc.

> Because Email may not be the optimal user interface for handling issues, pull requests, code review, etc.

Maybe that's your experience.

Others have used mailing lists for this purpose for decades and a lot of people prefer it.

For one, it's accessible. Every machine can do plaintext email. Every text editor can work with plaintext. It's simple. Integrate it into whatever shell/editor/scripting language you prefer.

As opposed to login into to a bespoke web interface, mainly primarily designed to be friendly to novice users.

>and a lot of people prefer it.

If this in true then why do so few projects use a mailing list nowadays instead of something like github.

>Every machine can do plaintext email.

Every machine can do web browsing too. More people have used a web browser on their computer than a dedicated email client (as opposed to a web app like gmail).

>As opposed to login into to a bespoke web interface

You have to log in to email too.

>mainly primarily designed to be friendly to novice users.

What's wrong with that? Having good UX is a win. The UX for creating a new repo on github is a million times better than creating a mailing list (yes I have set up a mailing list for a project I made and no one e ended up using it except for me. Meanwhile I had much more success with getting people to join and discuss the project via Discord)

> If this in true then why do so few projects use a mailing list nowadays instead of something like github.

Lot's of projects use mailing lists. Lot's of projects use web-based git hosting services. Lot's of projects mix.

Why do people just use GitHub? Because it requires zero configuration and it's convenient when you're developing something yourself.

The Linux Kernel is by far the worlds largest open source project. Consider that it might have different needs.

>> Every machine can do plaintext email.

> Every machine can do web browsing too.

You're missing the point. A web interface is more complex than plaintext emails. To integrate into your shell environment is a lot more complicated.

> More people have used a web browser on their computer than a dedicated email client (as opposed to a web app like gmail).

I don't understand your point.

>> As opposed to login into to a bespoke web interface

> You have to log in to email too.

The emphasis was on bespoke web interface, not logging in.

>>mainly primarily designed to be friendly to novice users.

>What's wrong with that?

Fast and flexible are sacrificed. Ie. it's more convenient for the people who don't use the system all the time (people filing bug-reports) vs. the people who actually use it all the time (maintainers)

> yes I have set up a mailing list for a project I made and no one e ended up using it except for me

a tad different use-case to the development of the linux kernel it seems

> Meanwhile I had much more success with getting people to join and discuss the project via Discord

Whatever works for your project bro.

> Every machine can do web browsing too.

Tell that to most of my browsers which refuse to display any Gitlab content (they only ever show the side bar).

>> mainly primarily designed to be friendly to novice users.

> What's wrong with that? Having good UX is a win.

What's "good UX for novice users" isn't necessarily good UX for more advanced ones.

> Isn't this also a problem if the person managing the email list goes rogue? You have to trust someone to host the infrastructure.

It depends on what kind of threat you are worried about. The beautiful thing is even if LKML was abused and ruined tomorrow, nothing is lost or damaged. The emails have already been sent, and moving to a new list is more of a nuisance at this point.

If you're worried about authenticating a patch series, committers can sign their commits a number of ways.

Lastly, a large chunk of Linux development happens off-list, with subsystem maintainers building branches for Linus or Greg to pull from.

I can't stop laughing at the idea of GitLab struggling to render 100k lines of changes.

Please actually attempt the ideas you are suggesting before suggesting them.

This set of changes (and other large ones like it) is partially why the kernel needs to use email instead of <insert bloated Ruby application here>.

GitLab is awful and slow at rendering large changes. Sometimes when folding and unfolding files, the scroll position will jump around (though I'm unsure if that's a browser extension). And when viewing standalone files, KDE's Invent GitLab server is slow and can take 5-10 seconds to render a few thousand lines and send it to the client as JSON with syntax highlighting, before the file contents show up.

> GitLab is awful and slow at rendering large changes

So’s github, anything of a non-trivial size it just won’t show by default and you need to re-request every time.

It starts struggling around the kloc scale, and the browser itself soon follows as the dom is not the neatest and you start getting tab memory above half a gig, which I assume also makes the JS start killing itself or something.

Good times.

gitlab can't render this changeset. gitlab has a limit what it can render.

> why the kernel needs to use email instead of

This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true. Using email is very much an intentional choice and a desirable solution.

>This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true.

The mailing list that they use now is centralized. It works by everyone sending a message to a single email address. The owner of that address then sends the email out to all of the subscrbers of the mailing list.

Having everyone who wants to upstream their patch directly to the kernel submit their work to a single website is not much different than them sending it to a single email.

But that isn't how it works right? You send your pull requests to the relevant maintainer, CC people that you think should be aware _and_ send it to the mailing list (probably also "only" via CC).

This here for example is sent to Linus directly and that part does _not_ depend on the mailing list. The mailing list is just a convenience feature for people that _want_ to be aware but may be looked over/forgotten by the submitter (which still happens, and people regularly say stuff like "also CC'ing additional relevant people").

Yes you could, at least in principle, also do that via GitHub/GitLab/whatever. But a) you wouldn't gain anything (the kernel already has all the tooling it needs and it's large enough to just create missing tools, heck git was literally written for it), b) you would introduce a massive single point of failure that either i) is _not_ under control of the kernel.org team or ii) needs a massive amount of resources to host (see the fun people poke at displaying 2k commits in GitLab). Neither seems like a good use of the kernel development resources. And if you want to contribute to the kernel... using a mailing list is an absolutely trivial problem.

Yeah which is why I put the word "partially" in front of that out of context quote.

It's not like you would render and display the diffs in 2k emails at the same time either.

There’s no reason you couldn’t. And part of the beauty of patch emails containing full diffs is that you can take them and use whatever tool you want to render them and not be beholden to some dumb web UI’s opinion of what’s “too big.”

The difference is in one case a centralized server is expending a lot of resources to show something to the user, and in the other case it all happens locally and has no effect on the kernel.org infrastructure.

I don't think the issue is with the centralized server, but the browser and the JS components they use. I prefer local anyhow.

Didn't git do exactly that in preparing those emails to be sent? I wonder how long it took for that command to run.

Probably very, very quickly. git-format-patch is very fast; all it has to do is diff the files involved in each commit, which is already heavily optimized. No syntax highlighting (your email program can do that if you want it), or line numbering (ditto).

61.65 seconds to create all 2,298 emails on my computer, with the repository on spinning rust. That’s about one fortieth of a second each on average.

Don't discount the heaviness of rendering the HTML on the client, too!

I'm sure it could handle you viewing each commit one at a time just how with email you would look at each commit one at a time.

I have actually came to appreciate email much more than I used to. There are so many bad implementations of email, that for years I was on the bandwagon of having something else replace email.

Then I came to realize that my problem was not with email itself, but the way I had been using it. All GitHub, GitLab, etc do is take a decentralized platform and add centralization. I love the idea of using email now instead of a centralized issue tracker. Mailing lists become the issue tracker and those are then published on a website for others to use that want some centralized features.

A mailing list is a centralized platform. Just as the internet / web is decentralized and github lives on the web. Email is decentralized and a mailing list lives on email.

Centralized in this instance means one provider controlling the platform. GitHub is owned and controlled by Microsoft and therefore has a descent amount of vendor lock-in. Email is not controlled by a single provider and if configured correctly, you can easily migrate email between various providers or host it yourself. Email uses open standards.

A mailing list is centralized, but much less so than GitHub and is secondary in this instance.

> 0 siblings, 0 replies; only message in thread

Ingo did not send 2298 patch emails, he sent only the 0000 one, which contains the location of his public git repo for all this. People can clone this, and can even push it to a github/gitlab/etc hosted repo if they like.

In fact, sending too many patches to the mailing list is frowned upon:

https://lkml.org/lkml/2005/7/11/336

Just checking here, but you are aware that the person who specifically likes the current process for managing the linux kernel sources is also the person who designed and implemented git, right? As in, Linus wrote git because he wanted a tool for managing sources exactly the way he wanted to do it. Is it any surprise that he has no desire to move away from that workflow?

Yes, I am aware of that, but I'm also aware that this is an ancient workflow. Git was released before I even used a computer for the first time.

I think it's natural for workflows to change overtime.

BDFLs gonna BDFL.

It's a fucking shame how many people nowadays can't grok the difference between git and GitHub.

Your question is fundamentally wrong; totally bass-ackwards. The correct question is:

When will all the zillion other projects move off of GitHub / GitLab / all the other usurper sites?

nobody is forcing you to read all of them

yeah just minimize the PR like I minimized this thread..

It just seems like a waste of resources to send all these emails to people who are not going to read them.

?? how?

it's plain-text email

the display ad on your local news website is probably wasting more resources

not for a very long time. The devs prefer email to github methods of communicating and patching.