it's kinda worrying that the email/patch workflow doesn't really have a mechanism to prevent maintainers from making subtle changes to patches. these could be pretty difficult to spot too

EDIT: I know patches can be signed, I guess there is probably a way to have this signature remain valid all the way until torvalds tree? Yeah just thought I should clarify before inadvertantly spreading FUD.

at least with a git forge you're putting trust into the forge machinery and with fast forward merges on signed commits you can be sure that nothing was modified.

@cas now that is a point

@whynothugo yeah i know there are many ways this doesn't work with a git forge... and certainly the workflows we have aren't really designed around this. But at least it's possible with fast forward merging

@cas yup, i had one case where i accidentally broke something after a rebase and didn't test it, and it got in... 🙃

i like what e.g. gitlab does for this, where you can view the diff between different versions of the merge request, so you can quickly spot any changes

@cas Yeah they should just move to a forge already

I wonder if this will happen once forgejo completes their federation efforts, and also someone could even make it support opening pull requests via email

@luana as much as I appreciate the benefits of git forges, I do find this take a little reductive. The way that kernel or U-Boot development works just doesn't translate to even a federated forge approach...

Different parts of U-Boot are maintained by different people who have their own trees and way of doing things (see https://source.denx.de/u-boot/custodians)

But it isn't the responsibility of contributors to figure out which tree to contribute to, and sometimes one maintainer will pick up patches that change code which is technically the responsibility of another maintainer... Deciding which maintainer will pick up a patch series (or subset thereof) is somewhat arbitrary, depending on the series in question, other changes in-flight, and a bunch of other complicated context.

Attempting to flatten this to a single repository that everyone opens PRs to would make things much harder to keep track of imo

@cas @luana "Deciding which maintainer will pick up a patch series (or subset thereof) is somewhat arbitrary, depending on the series in question, other changes in-flight, and a bunch of other complicated context." One of the worst things in that regard is when you've got a new soc vendor and some newer contributors so noone's go the foggiest who should apply patches for it.

@conor @luana heh yeah having easy on-boarding and a community of people who have the energy (which we can't always rely on) to take responsibility for Cool New Shit™️ is fairly important here.

I gotta say I've found U-Boot really refreshing in this sense, I got onboarded as the Qualcomm maintainer really easily (fwiw in large part because my colleague is already a maintainer) and everyone other maintainer I've spoken to has been extremely chill. It makes me want to pay it forward and I think this is way more powerful than anything else.

@cas @luana Yeah, I think it's less of a issue in U-Boot cos Tom sees everything pretty much. Tom's great, but that's only possible cos ultimately the volume is about the size of a larger Linux subsystem AFAICT. It's much more noticeable in Linux for new SoC vendor stuff - drivers/soc and dts stuff is what I've mostly seen fall into the abyss of noone knowing who is meant to deal with it.

@conor @luana yeah you're definitely right about that.

@cas Sounds complicated to implement with email and the signed-off-by, reviewed-by... etc metadata that gets added. I guess you'd need to have a dedicated section for that in the commit that doesn't get signed.

Also it seems somewhat common for maintainers to squash minor fixes (e.g spelling) when applying a patch. Perhaps it's not good security wise, but it definitely makes it easier for new contributors.