This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.)
I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.)
It seems to work smoothly for the Linux kernel folks; clearly it doesn't have to be clunky.
> because git format-patch doesn’t mention what commit the patches do apply against, I’m more likely to encounter a conflict in the first place when trying to apply them.
It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to deal with (and mail servers? Fuck). Raw text with no concept of "review thread resolved" wastes loads of review energy manually tracking what feedback has or hasn't been addressed. Comparing old and new versions of a patchset (equivalent of a pull request) requires manually searching your mailbox for the different versions, manually applying them to your local repo (hopefully you can find the base commit the old version applies to, which by now might not even exist any more if it's an unstable maintainer branch) and then manually running git-range-diff.
As someone who works with an git-send-email workflow every day, I can tell you, it sucks. Email is not a good substrate for development.
If I were Linus I would be pestering the Linux Foundation to set up a bunch of managed Gerrit instances or something.
How do you know it's not a personal tooling issue? I have had very smooth email workflows using GNUS, and I imagine many Linux devs have their own scripts and/or customized clients to handle the email flow.
An argument could be made that developers shouldn't have to build their own workflow to do basic development tasks, but given Linus's past statements on C++ developers, I would assume that he would rather not have developers that cannot handle an email workflow working on Linux (that is, this is WAI).
Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.
> Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors.
No, it really, really wouldn't. The Linux workflow is optimized for the preferences of (a subset of) maintainers, notably Linus; it is not optimized for contributors.
The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails?
sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?
One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.
There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck.
There is also Patchew which I've never tried.
But overall everyone just has their own individual pile of shell scrips and mail client macros.
Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute?
You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works for many people. It's just not your preferred choice of tooling, which is... fine.
The fact that email is the lowest common denominator seems like a good thing to me. It allows everyone to use their tools of choice. As long as you can send and receive email, you can contribute. How you decide to integrate that into your development process is up to you. If you can't be bothered to setup a workflow from scratch, then you can adopt someone else's. I'd much rather have this choice, than be forced to use Gerrit or GitHub or whatever else.
I use b4, it largely solves sending code. It doesn't help with reviews though. (b4 shazam makes the manual application of patches to prepare a git-range-diff a bit easier but it's still basically a half baked process. It's fundamentally harder to to review patches than to review Git commits, a few thousand lines of Python won't make that reality go away).
> As long as you can send and receive email, you can contribute.
Sending and receiving email has so many barriers! The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use! Saying that email is a sensible lowest common denominator is crazy. The reality of it is that the kernel community is majorly dependent on GMail and GMail isn't even a good mail service for the job!
Using a git forge is dramatically easier to use and easier to set up, host and maintain.
However, AFAIK there isn't a forge that exists today that can actually meet the kernel's needs though. Switching to one would be a significant project. (But if the core maintainers wanted it, it would be very feasible).
> It's fundamentally harder to to review patches than to review Git commits
I'm not familiar with kernel development, but after you pull the patches locally, can't you simply review the commits via `git diff` or with whatever viewer you use? This is how I often review code when using GitHub. I only use the GH interface for sending my comments, which is what email in the kernel workflow is for.
The only thing a web-based tool is helpful for is for grouping discussions, and being able to reference or find them later. This might be more tedious with typical web-based email UIs, but most offer some kind of threading and search support, so it can't be that bad.
> Sending and receiving email has so many barriers!
Email has many problems, but I don't see barriers to using it as one of them. There are literally thousands of providers to choose from that could be suitable for sending and receiving patches.
> The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use!
linux.dev is not managed by the Linux Foundation but by Migadu. It's only offered as a convenience service for people on corporate networks who have no control over their email. They could just as well choose to use another provider.
> Using a git forge is dramatically easier to use and easier to set up, host and maintain.
You contradict this right in your next sentence. You're right that maintaining a centralized system at this scale would be a daunting task. Email being decentralized avoids this problem altogether.
The thing is that a "forge" provides several loosely-related services.
Sharing code is a basic one that Git already does quite well over HTTPS and SSH. What I don't understand is why the patches simply aren't shared this way instead of using email as the medium. The problems outlined in the original article are very real. Kernel development could follow a similar suggested model where URLs to pull from are shared instead, while keeping email strictly for reviews and discussions. This way everyone would be free to choose where they want to host their fork, and maintainers can simply pull from it. But I digress...
The other things forges are used for are code reviews, CI, bug tracking, planning, etc. It's debatable how helpful any of these services are, and many developers would have their own preference. You might like Gerrit, but that's not a universal opinion. And I think most developers would agree that code reviewing in GitHub or Gitlab is painful. If it was up to me, I would choose a tool like git-appraise instead, but I'm stuck with GitHub because that's what the teams I've worked on have preferred.
So my point is that email is likely not the best choice for this, but it's a reasonable one that's flexible enough to be usable by anyone. Forcing any other tool on everyone would likely displease an equal or greater amount of contributors, while also introducing maintenance and reliability problems.
The parent post already outlined the various problems. Not wanting to deal with all of that getting in the way of your actual work doesn't make you a "script kiddie" or mean you can't format an email
Yeah exactly. I can format an email. I can dig a hole in the ground to do a shit, but I prefer to use a toilet. Doesn't mean I can't dig holes.
If you want to deliberately exclude new developers (which is a stupid thing to want), you can do that. You don't have to additionally shoot yourself in the foot by sticking to a broken workflow as an instrumental goal.
I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git.
Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.
If you force them to use it anyway, very few people will use it.
DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug.
It falls flat on its face for larger projects and communities.
I think it would be necessary to do some manual copy+pasting, or else use custom scripts/tooling, to turn such mailing-list archive pages into patch files (for git apply) or mbox files (for git am).
See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)
I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.)
It seems to work smoothly for the Linux kernel folks; clearly it doesn't have to be clunky.
> because git format-patch doesn’t mention what commit the patches do apply against, I’m more likely to encounter a conflict in the first place when trying to apply them.
This is what the --base flag is for. [2]
[0] https://git-send-email.io/
[1] https://git-am.io/
[2] https://git-scm.com/docs/git-format-patch#Documentation/git-...