On Tue, Jun 17, 2025 at 07:49:11PM +0300, Otto Kekäläinen wrote: > > A person with your seniority surely knows better commands to use than > review plain diffs. Naturally, it is better to review using the git > log -p output that shows each commit message individually and related > changes.
You *can* use "git log -p", but now responding to a commit to request changes gets much harder. So this puts a psychological pressure on a developer to just say f*ck it, I'll just accept the pull request. Which might not be in the best long-term interest of the project. *If* the pull request is fully linear, you can do something like "git format-patch --stdout main..pull-branch > /tmp/patch.mbox", and then pull it into a e-mail reader, with a command like "mutt -f /tmp/patch.mbox", and then reply to each patch individually. The downside with this, though, is that we lose mail-threading and other developers in the project can collaberatively review patches over a mailing list. And people who uploaded the patch to a Forge won't see the comments in the Forge's pull request. If they don't read e-mail, then they won't see the replies --- just as people who don't monitor salsa won't see the pull requests. Oh, well.... > Sure it is more convenient to, you as you most likely have some well > optimized Emacs email setup going on. But more secure? Surely signed > commits and a system that tracks real git commits and who pushed what > from where is more secure than plain-text patches in e-mail. People aren't using signed commits on most Forges. And even they do, they signanture doesn't mean much when they come from newbie contributors. The main issue, though, is that you *should* be doing line-by-line patch review, and so the authentication comes from the person doing the review assuring that the patch is good, and has no bugs, either introduced accidentally or maliciously. And for the record, no, I don't use Emacs to read my e-mail. I happen to use mutt, with fairly generic settings. > Note that I am not claiming that the current UX of e.g. GitLab is > perfect. There are many things to improve, for example the default > MR review vies should show all commit message as an expanded list > instead of hiding them. My point here is that your e-mail setup is > something you have optimized for years. I don't think it is > something the next generation of devs is going to adopt. I don't think we can say for certiain that *everyone* in the next generation of developers are going to be using any particular workflow. I'm not even going to worry much if the majority of the next generation developers are going to be using e-mail. It might be that we have an order or more of developers who use TikTok and who do vibe coding where they say something like, "ChatGPT, create me a program that manages my pool cleaning schedule". So what if we have gazillions of low-quality devs that don't know how to program except by asking a LLM to write code for them, and who refuse to use e-mail? I don't care about them. What I care about the absolute number of highly skilled developers who can do proper architectural design, writes regression tests, and know how to maintain stable ABI so that they can maintain a shared library initerface for ever a decade without breaking backwards compatibility. And so far, I haven't seen a decline in the number of people are becoming new kernel developers, with our "archiac" workflow requirements. So personally, I'm not terribly worried about "the next generation of developers". I just care about the next generation of highly qualified developers. And I find it hard to believe that these people won't be using e-mail, but only using Instagram or TikTok --- and Forges, and are not capable of using any other workflow. > fetch CI statuses from external APIs... So a couple of things here. I think you need to distinguish between unit tests and integration tests. Unit tests should be fast, and should be able to run on your local development machine. So you don't need an e-mail interface for them. I just do something like "make -j28 check" and I get an answer back in under a minute. *Hopefully* the contributor will have run the regression test suite because it's super fast, and if it turns out that they haven't because their patch causes regression test failures (or worse, doesn't even compile), then it's up to the maintainer to show the contributor the error of their ways. :-) As far as integration tests are concerned, those take long enough that you want to do them off your local machine. And if they are well curated so you are 100% green, or close to that, then you don't need a fancy e-mail interface. You just need an e-mail message telling you thtat there is a test failure, and optionally, maybe you have your CI system do an automatic bisect. When I'm in a low-bandwidth environment, I just have something like this running: gce-xfstests ltm --repo https://github.com/tytso/ext4 --watch -g auto I can then just do a push to the test branch, and the lightweight test manager will notice that the branch has changed, and start a build VM which builds the kernel, and then launch 12 VM's for various different file system configs. When all of the tests are completed, which takes roughly 25 VM hours, and 2.5 hours of wall clock time (and $2 USD of cloud VM's at retail prices), the test results are aggregated and a summary e-mail gets sent. (The test artifacts are saved so that if you want to root cause a failure, they are easily accessible via the gce-xfstests get-results command.) And of course, all of this is open source, and built on top of Debian, so other developers can use this setup[1]. [1] https://thunk.org/gce-xfstests See? No forges are required. Just a git repo, which could be on github, but it could just as easily be on Salsa or git.kernel.org. - Ted P.S. I will note that Intel is also currently running a "zero-day test bot" which watches the Linux kernel mailing list for patches, and it will automatically apply the patches, and run both functional and performance tests. If there are any test regressions or significant changes in performance (either positively or negatively) an e-mail gets sent automatically to the subsystem maintainer and to the person who authored the patches. Again, no forges are required.
