5 ms·

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 u

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.

imiric 2y ago
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.
- JoshTriplett 2y ago
  > 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.
karel-3d 2y ago
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.
- bjackman 2y ago
  No there are no standardised tools. 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.
  - imiric 2y ago
    > No there are no standardised tools. 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. [1]: https://b4.docs.kernel.org/ https://b4.docs.kernel.org/ [2]: https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.html https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.ht...
    - bjackman 2y ago
      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). [0] https://korg.docs.kernel.org/linuxdev.html https://korg.docs.kernel.org/linuxdev.html
sph 2y ago
[flagged]
- didntcheck 2y ago
  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
  - bjackman 2y ago
    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.
Ferret7446 2y ago
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).

imiric 2y ago

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.

JoshTriplett 2y ago
> 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.

karel-3d 2y ago

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.

bjackman 2y ago
No there are no standardised tools. 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.
- imiric 2y ago
  > No there are no standardised tools. 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. [1]: https://b4.docs.kernel.org/ https://b4.docs.kernel.org/ [2]: https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.html https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.ht...
  - bjackman 2y ago
    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). [0] https://korg.docs.kernel.org/linuxdev.html https://korg.docs.kernel.org/linuxdev.html

sph 2y ago

[flagged]

didntcheck 2y ago
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
- bjackman 2y ago
  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.

Ferret7446 2y ago

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