.. > 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....
You are aware that you can send e-mail to a MR on GitHub and to a PR on GitLab and pretty much every Forge supports both email notifications and email replies? The only feature currently missing in GitLab is to have the notification of a new MR have the actual patch attached so people using e-mail only can read it and reply directly. > > 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. Yes, but as soon as you get the second or third contribution, the ability to attribute the submissions to the same submitter with higher guarantees will start to matter. > And for the record, no, I don't use Emacs to read my e-mail. I happen > to use mutt, with fairly generic settings. Thanks for sharing, this was an interesting data point. ... > 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. I've seen some of this same sentiment in discussions about bugs.debian.org. People think that having a hard-to-use bug tracker will keep the "noobs" away and maintain a higher quality of bug reports and discussions among the people who do pass the bar of figuring out how to use it. I think this is a very elitist attitude. Also, I see a lot of bugs that have low-quality participation exactly because participants got past the barrier of figuring out how to interact with it, but didn't figure out how to do it properly and for example attach metadata on what is the upstream bug report URL correctly. Personally I'd rather have low barrier of entry and other mechanisms to track contributor reputation and gatekeep contribution quality, such as tools that make purging spam easy. I just merged a first-time contributor MR in https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/614, and I think it was good quality. I don't think that people who use MRs are noobs and their quality is in general bad, and I don't think this barrier of e-mail-only really helps drive up contribution quality. When I compare my experiences of top-tier developers who I have seen doing both e-mail reviews and in-browser reviews, in my experience their in-browser reviews end up being much more productive and scalable as they can have rich context information that is always up-to-date, can track statuses and in general juggle many more reviews in parallel. Also, if a bug goes into production, having the track record properly in git and Forges really makes a difference. But as said, I understand you have now your optimized workflow in Mutt, and I am not asking you to change it. I just wanted to point out that some claims of how the Forges work or don't work were not entirely accurate. Also, when you went from discussing the utility of reviews in e-mail vs Forges to talking about people who don't use e-mail *at all*, and then mention software development driven by TikTok and Instagram, I think this discussion probably has seen the best arguments and we can conclude here.
