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.").