Email or username:

Password:

Forgot your password?
Hector's posts Post Back to profile
Hector Martin

Hi (some) kernel folks: please stop trying to convince me (and the rest of the world) that email patches are better.

They aren't, and the rest of the world knows that already. We're tired, and countless people have been driven away from contributing thanks to this utterly broken process.

Before you manage to drive *me* and all my contributors away, I *will* start pushing alternate mechanisms for trees I am involved with. If you don't like it, tough luck. Complain to Linus, and make sure he knows if he kicks me out his shiny M2 MacBook no longer gets upstream support.

14 Feb 2023 at 16:17 | Open on social.treehouse.systems
41 comments
Jo Shields

@marcan I think email is still somehow less shitty than the stupid-ass Phabricator shit LLVM uses.

14 Feb 2023 at 16:20 | Open on tech.lgbt
The-Mentor

@marcan sometimes you need to bring up a storm and create a huge backlash to make people realize how broken something is.

I'm sure a lot of good developers gave up and will never try to contribute to the kernel again.

A better process makes it better for everyone

14 Feb 2023 at 16:21 | Open on kan.social
mort

@dm @marcan Hi, I'm one of them. I have some patches to work around kernel bugs which I can't be bothered to upstream. I've tried to use FOSS mailing before, to report issues and propose bug fixes, and every single time they've just been ignored forever. It seems if you don't get attention in the first week or two there's no hope. It's just not worth it.

Compare that to GitHub/Gitlab/whatever, where I've always gotten a response, had my bug fixes merged, bug reports attended to, etc.

14 Feb 2023 at 16:58 | Open on fosstodon.org
K. Ryabitsev
@mort @dm @marcan This has nothing to do with the platform, really. I've reported many (what I consider) critical bugs to Python where they've been sitting in the shiny Github bugtracker without any movement. Your patches are ignored NOT because they were sent via email -- there's just nobody looking at them (because they are on vacation, tired, burned out, sick, etc).
14 Feb 2023 at 19:07 | Open on social.kernel.org
jackson

@marcan how are email patches not better than (implied from previous posts) the web/github PR+review model?

14 Feb 2023 at 16:24 | Open on micro.jacksonchen666.com
Charlotte 🦝 θΔ

@jacksonchen666 @marcan it’s what has been done since literally forever and therefore it must be good

14 Feb 2023 at 16:33 | Open on akko.chir.rs
Sven Slootweg

@jacksonchen666 @marcan On the off-chance that this is a good-faith question, I'll point out one specific issue from which most of the practical issues derive:

E-mail based patches are based on convention, not on technical formats.

This means that to contribute, you have to learn and memorize a bunch of arcane conventions, and never get them wrong, or the tooling will get confused and good luck figuring out how to fix it.

It also means that eg. the review process cannot be as granular as something with a dedicated review UI; it's not possible to render an easily navigable 'review history' (see eg. Github PR review threads) unless every review comment includes a bunch of metadata.

And to include that bunch of metadata over e-mail, every user needs to learn more conventions, because e-mail clients are not built to do any of this, so there's no UI for it.

So either you have less metadata and can't render useful outputs, or you have more metadata and require people to memorize absurd amounts of conventions.

There is no good solution there.

We have dedicated UIs for things for a reason - they are more accessible because things have a clear purpose, and don't require constant memorization. How it works internally is a separate matter, but that UI *has* to be there to make it accessible.

(I'm not interested in further discussion on this topic; this should be enough of a pointer to think about other usability/accessibility issues that spring forth from this problem.)

@jacksonchen666 @marcan On the off-chance that this is a good-faith question, I'll point out one specific issue from which most of the practical issues derive:

E-mail based patches are based on convention, not on technical formats.

This means that to contribute, you have to learn and memorize a bunch of arcane conventions, and never get them wrong, or the tooling will get confused and good luck figuring out how to fix it.

14 Feb 2023 at 16:41 | Open on social.pixie.town
Sven Slootweg

@jacksonchen666 @marcan (Also, if this was indeed a good-faith question, apologies for being a bit cold in my response. I've unfortunately had to deal with a lot of necrocomputing enthusiasts who ask exactly this type of question in bad faith.)

14 Feb 2023 at 17:42 | Open on social.pixie.town
nadja

@marcan FWIW I wholeheartedly support you; and I may very well have been one of those people driven away from contributing due to this.

Kernels and C programming are areas I have solid expertise in but the arcane process of the Linux kernel always made me rather wary to try to help out, so I never tried and never found out if it is really that bad.

14 Feb 2023 at 16:26 | Open on mastodon.chaosfield.at
Karl

@marcan Curious to know what arguments are in favor of email patches.

Modern front-ends for git servers are literally providing an equivalent feature set but more convenient.

14 Feb 2023 at 16:28 | Open on infosec.exchange
Hector Martin

@karl "I can do patch reviews from Emacs"

Stuff like that.

14 Feb 2023 at 16:36 | Open on social.treehouse.systems
Arnaud

@marcan @karl Well I can review github PRs from vscode 😄

14 Feb 2023 at 16:47 | Open on mastodon.online
Ongion

@marcan @karl well, emacs is open source, so they should be able to add GitHub PR support to emacs themselves! 😉

14 Feb 2023 at 16:59 | Open on mendeddrum.org
sirocyl

@marcan @karl my universal response for "but it wouldn't work in emacs" is "well then, fix emacs yourself, it's Free Software, you know, you're a capable programmer" in much the same vein that they argue whenever anyone else has an issue with free software. Ugh.

14 Feb 2023 at 17:01 | Open on social.treehouse.systems
Neal Gompa (ニール・ゴンパ) :fedora:

@marcan @karl I use Emacs. There are GitHub, GitLab, Pagure, Phabricator, and Gerrit clients for Emacs. You don't *have* to suffer through email for just that.

14 Feb 2023 at 17:16 | Open on fosstodon.org
Alyssa Rosenzweig 💜

@marcan @karl

I do GitLab patch reviews from vim, e-mail style... it annoys other devs sometimes but it's far better for everyone than e-mail 😅

14 Feb 2023 at 17:31 | Open on social.treehouse.systems
Karl

@marcan I haven't checked, but I'm sure there are some plug-ins out there that make emacs work with github/gitlab and friends.

If the other "reasons" given are of the same kind, it sounds to me like a disingenuous excuse to not change a workflow they have gotten used to. I am not impressed.

14 Feb 2023 at 17:32 | Open on infosec.exchange
LisPi

@karl @marcan All of which are individually incompatible and non-standard, complicating #interoperability.

#Email isn't amazing for sharing code, but neither are Github-style pull-requests.

We need something better than either of those two.

The centralized #API-driven workflow of #Github clones is also problematic because of what it does to #git as a #distributed system and its lack of resilience.

sourcehut.org/blog/2020-10-29-

14 Feb 2023 at 18:23 | Open on mastodon.top
LisPi

@karl @marcan A large part of that is entirely #git's fault, because #FossilSCM has no such problem (it has different ones instead mostly from its focus on cathedral development...).

Git's design insistence on carrying none of the other project metadata and tooling required for its use is a problem.

14 Feb 2023 at 18:31 | Open on mastodon.top
Glitch

@marcan While it’s not great, it is one of the few truly federated systems of development. With the traditional “central git server + issue tracker + PR merge interface” methodology you do have both that centralized issue where it becomes hard to ship out your data, a big single point of failure and in the case of the Linux kernel, a pretty juicy attack target for hacking and spamming.

Another issue is that pretty much all hosted git solutions that currently exist don’t… really expect you to CLI merge except for SourceHut, but SourceHut literally exists because Drew wanted to have the mailing list development approach. They all can do it in a way where the server software will recognize the merge, but it’s often poorly documented and they’d much rather have you click the big merge button on the website.

Idk, I don’t think there’s a great answer here.

@marcan While it’s not great, it is one of the few truly federated systems of development. With the traditional “central git server + issue tracker + PR merge interface” methodology you do have both that centralized issue where it becomes hard to ship out your data, a big single point of failure and in the case of the Linux kernel, a pretty juicy attack target for hacking and spamming.

14 Feb 2023 at 16:30 | Open on pl.glitch.pm
Thomas Frans 🇺🇦
Wanja

@marcan Agree fully.

One of the main advantages that NixOS brought for me is the fact that I can just make a PR if I want to fix something, instead of having to jump through all the weird hoops that e.g. Debian would make me jump through to do anything. I would love if contributing to the kernel was that easy too!

14 Feb 2023 at 16:35 | Open on hachyderm.io
Jens Axboe

@marcan Email sucks (and is broken), that's a fact. As a maintainer it's manageable with things like lei and b4, but would be nice with a different backend than email.

Various core maintainers do already share your sentiment. There's no great solution so far though, unfortunately. Personally I would still much rather review patches in email than some horrid github/whatever web interface. But I realize that email isn't for everyone, and am happy to try and be flexible.

14 Feb 2023 at 16:35 | Open on fosstodon.org
Hector Martin

@axboe Note that these systems do have APIs, so it's not like you can't build alternate clients for them (and people do). But I'm actually curious, what do to find horrid about the web interfaces? I mean it takes some getting used to of course, but other than that?

Besides avoiding the pain of the email process, there are lots of little benefits. Stuff like being able to see at a glance what's reviewed and not, whether the reviews come from owners or third parties, batching of review feedback until you finish with all the commits (so you can go back and edit things before sending), the edit buttons everywhere in general even after sending, being able to directly send mergeable suggestions to the submitter, integrated CI that can block merging if desired, much more structured metadata to search/organize/tag things by, much easier integration with bots for custom processes, the fact that *all this state is shared* so individual people don't have to re-invent state extraction and management tooling for private use, ...

@axboe Note that these systems do have APIs, so it's not like you can't build alternate clients for them (and people do). But I'm actually curious, what do to find horrid about the web interfaces? I mean it takes some getting used to of course, but other than that?

Besides avoiding the pain of the email process, there are lots of little benefits. Stuff like being able to see at a glance what's reviewed and not, whether the reviews come from owners or third parties, batching of review feedback until...

14 Feb 2023 at 17:07 | Open on social.treehouse.systems
Alyssa Rosenzweig 💜

@axboe @marcan As I mentioned elsewhere I review a lot of GitLab patches in a CLI... Janky python script I wrote to fetch down git format-patch style output of an merge request, open it in vim, let me mark it up in vim the same way I would e-mail, and then upload whatever I wrote as comments on the merge request. It's not integrated with the GitLab review UI which annoys some people, but it's still a hell of a lot better than e-mail.

IDK if something like that would be a nice compromise for folks like you, I guess it depends which part of e-mail review you depend on.

@axboe @marcan As I mentioned elsewhere I review a lot of GitLab patches in a CLI... Janky python script I wrote to fetch down git format-patch style output of an merge request, open it in vim, let me mark it up in vim the same way I would e-mail, and then upload whatever I wrote as comments on the merge request. It's not integrated with the GitLab review UI which annoys some people, but it's still a hell of a lot better than e-mail.

14 Feb 2023 at 17:45 | Open on social.treehouse.systems
Arch :arch:

@marcan It is genuinely the biggest blocker for my own personal want to contribute in any way. I tried to subscribe to some mailing lists to try and understand the process but it was so hard to get any sort of handle on the volume of emails (maybe I'm doing mailing lists wrong?) and started to get spam on top of that so quickly dropped it all :/ I really hope it evolves in some way.

14 Feb 2023 at 16:37 | Open on floofy.tech
TSource Engine Query
CULTPONY :verified: :v_bi:

@marcan But how will people reenact their own personal Game of Thrones political scheming without the availability of Email and Git Commit Headers like Acked-By, Reviewed-By, Politically-Married-To, Invaded-By, Backstabbed-For, Crowned-As and Betrayed-By?

14 Feb 2023 at 16:49 | Open on pony.social
DeviantXS

@cult @marcan “The sacred emails!” - Some contributor

I hate email by design and by everything it stands. I rather use dial-up internet at that point.

I do understand some of its use cases though, but still… goddam email clients be a maze.

14 Feb 2023 at 16:57 | Open on pony.social
CULTPONY :verified: :v_bi:

@DeviantXS @marcan Also a reason why I refuse to report bugs to Debian's bug tracker, despite having had to cleanup behind Debian maintainers at work.

14 Feb 2023 at 17:09 | Open on pony.social
gudenau

@marcan Honestly all of these horror stories are making me never want to actually try to get anything into the Kernel.

14 Feb 2023 at 17:12 | Open on fosstodon.org
Lorenzo🐧

@marcan 'Complain to Linus, and make sure he knows if he kicks me out his shiny M2 MacBook no longer gets upstream support.' is just toxic dude. I really wish you would stop with that kind of thing, my whole criticism of you before was that you use your social media presence to effectively attack kernel maintainers
I thought maybe I was wrong. But you know, maybe I was right first time.

14 Feb 2023 at 17:35 | Open on fosstodon.org
cybik :deifirev:

@ljs because gaslighting a dev airing their legitimate grievances publically works so well.

14 Feb 2023 at 17:44 | Open on sms.cybik.moe
Lorenzo🐧

@root he has literally published a series of posts attacking maintainers. In what way exactly am I gaslighting by pointing that fact out and airing my view as a minor kernel contributor to a famous Wikipedia entry dude with a big frankly sychophantic following that maybe it isn't constructive?

I am also entitled to my view which I am expressing politely, please try to do me the same courtesy.

14 Feb 2023 at 17:53 | Open on fosstodon.org
Scott Perry

@marcan Seriously, Review Board is as old as the hills (and came out of a solid company email review culture during our early days at VMware! you can probably still interact with it using email!) and was a dramatic improvement over a pure email process.

14 Feb 2023 at 18:44 | Open on xoxo.zone
Go Up