On Tue, Jun 17, 2025 at 11:15:55PM +0300, Otto Kekäläinen wrote: > 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.
When there is a forge that will take a pull request with 20 commits, will send me 20 e-mails, one for each patch, and when I reply in-line with "here you didn't check an error return", and, "umm, isn't his an invitation to a buffer overrun attack" it gets translated into a comment for that particular line of code --- let me know. That would be great! > 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. It only matters if you are willing to let the 2nd or 3rd contribution get a lower level of code review. And if you do *that*, then all the attacker from the NSA or the Chiense Ministry of State Security needs to do is to send two valid contributions, and the the *third* contribution contains the backdoor. The reality is that even for someone that I know for over a decade, have met in person at least once a year, and I have exchanged GPG keys, they still might mistake that I'll catch in a code review. And sometimes I'll make a mistake that they will catch. Cryptographic signing doesn't protect you against mistakes. So while someone like Jan Kara or Darrick Wong *could* sign their e-mailed patches, they don't bother and I don't ask for it, because I'm *still* going to review their patches. And again, I ***hope*** Debian Developers are doing this, and not relying on cryptographic attestations, and just going Hurr, Durr. "OK, Git Pulled!" > 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. There *are* some first-time merge reqeusts that can be high quality; I'm not denying. However, *statistically*, there are far more crappy code reviews that I see on github compared to the ones that I receive via e-mail. And the ones that get sent via e-mail can get reviewed by a half-dozen people on the linux-ext4 mailing list. Things that get sent on github only get reviewed by me. So at least for the ext4 development comunity, the quality of e-mail versus Forge submissions is like night and day. Orders of magnitude worse. And as I mentioned in another e-mail, if you look at the quality of bugs on Ubuntu's Launchpad, or Sourceforge, or github, or kernel.bugzilla.org, versus the ones that get sent to linux-e...@vger.kernel.org, or to Debian BTS, again, my experience is that it is like night and day. Perhaps this is because for file systems, 9 times out of ten, a file system corruption is caused by hardware errors --- cabling, RAM, media errors, user pulling out the thumb drive, etc. So the vast majority of "bug reports" are really support requests where the problem was in the user configurtion. (And of course, most users don't keep backups....) So the vast majority of the bug reports don't have clean reproducers. And then there are the users who get confused when systemd creates a namespace, and so "unmount" doesn't actually unmount the file system because the file system is mounted in some namespace (or a bind mount) --- and then they file a bug report. If users are paying $$$ for a support contract with Red Hat or SuSE, then they can afford to have Level 1 support personnel to gently help them with PEBKAC problems. But if all of these bug reports show up in a web-based bug tracker which Debian Developers do you expect will handle them, precisely? And this is not a hypothetical scenario --- I've *seen* it, and I can't help all of those users; I don't just don't scale. (Which is why Red Hat, SuSE, IBM, etc., have L1, L2, and L3 support personnel; users don't get to talk to developers directly except in very rare cases, or unless they are paying $$$$$.) - Ted
