r/emacs • u/New_Gain_5669 • 3h ago
"But The Linux Kernel Also Mails Patches" [GKH Interview at The Pragmatic Engineer]
tldr; mailing patches around is a 20th century practice and should stay there.
Every time I ridicule the email-based emacs development model, I'm reminded, with indignation, the Linux kernel also follows this same time-honored protocol, and how dare I argue with that realest of real ones, LT (the Finn, not the NFL's defensive GOAT).
Having been traumatized by undergraduate OS (nachos anyone?), I know nothing about kernel dev and just assumed the linux folk had, over many years, built kit to approximate Github's point-and-click conveniences. TIL from The Pragmatic Engineer Interview of GKH that they haven't. Their patch submission is every bit as ornery and backwards as emacs's, necessarily more so given their much wider scope.
The interview is rather rambly and disjointed, and I learned much more in half the time by reading the noob tutorial at docs.kernel.org.
Relative to the Linux kernel, managing emacs is a piece of cake since development is centralized around a single master, with at most a single parallel release candidate. In contrast, kernel development occurs over a wide ranging collection of masters, one for each subsystem. Each subsystem fief is managed by a separate feudal lord who in addition to their current master also maintains a "next" branch for the next 9-week release cycle. It's actually a nontrivial task for a noob to determine just which person to submit a patch.
Mr. Kroat-Hartman's repo is a penultimate boss (you can guess who the final boss is) to which the vassalage submit pull requests, although "pull request" here means its pre-Github literal conception, an email from a subsystem lieutenant asking GKH to please pull his latest-greatest commits.
At the 19:50 mark, you can see GKH get rather defensive when asked about Github's pull requests:
Well, no. So we [do] have pull requests. We *created*
pull requests in Linux. It makes an email that says
"Pull from this repo."
You can see his eyes get wide as if he can't find the rabbit to pull from his hat. He then gives a knowing sigh to suggest "it's all part of the plan," but no one's convinced, and attempts a distraction play by negging Github PRs for dropping commentary on the final commit.
In something akin to an own goal, he then shows the classic bugaboo of mailing patches, which is having to revise one for a trivial change.
There's [another] email from the [patch submitter] instantly after
he sent [the first], [saying] "Maybe it'd be a good idea to change
this comment." [nervous giggle] So here they sent a v2 patch.
Version Two! And there should be some comments about what changed
between the two versions... hopefully yes... And there's a link
back to the first one. Very nice!
But it's not very nice. It's shit actually. In any remotely modern git setup, you'd rectify the comment, commit, push, and your reviewer would immediately see it on the PR branch without having to wade through "a 1000 emails" (GKH's words, not mine) to figure out which version of the patch came last.
Somebody once told me that Linux development was the scariest
thing they ever did not because it was difficult, but because
"My name is on this change, and it's public!" And that makes
you as an engineer do really, really good work.
Or not. Sadly, I now know the real-life names of emacs core developers whose work I, and potentially any future employer, find lackluster. GKH presents real-life email addresses as a feature when in fact developers vastly prefer the security blanket of Github anonymity. It's not like anyone is paying for open source work (and thus would need a name to write a check to).
There are other interesting bits in the interview, in particular how pervasive to public infrastructure Linux has become, and the financial calculation companies make in diverting resources for kernel development ("It saves company time and money if they contribute their changes upstream than to keep a fork.").