visionfive 1 didn't either IIRC, mildy annoying given their u-boot is fairly old and given the boards age, out of tree.

Doesn't come with support for "tftp" in the default config :(

@palmer nope, just arrived today. Need to swap out whatever default bootloader setup it's got to something TFTP-able before I do anything else w/ it.

Finally :)

This time without a dirty mat!

The diagnostics from clangd really suffer from too many false positives. Mostly ends up getting ignored, even when it's right, as a result :/

@gmarkall That sounds perfect really. Better than my face appearing, thats for sure!

@ljs all of mine are named after characters in Bob the Builder. I never even watched Bob the Builder as a kid...
I like seeing what people's message-ids are, shows personality :)

@ljs meh, there's nothing cringe about it imo

@llvm @marcan So I did go watch https://www.youtube.com/watch?v=lzdpO3kyoE0 & it's not as bad as I expected it to be. The goal there does actually seem fairly aligned - making the experience less frustrating for contributors & maintainers.
But at the same time, yeah documenting differences is less helpful to contributors than dropping the differences altogether. And some of the stuff, like suggesting maintainers should document that they commit their own material without sending it out for review instead of just not doing it I would have to disagree with.
Hard subject to even attempt to stand up and make "directed" suggestions about at LPC though!

@mupuf @sima @jani @ljs @marcan Right, I figured it was going to be some DRM thing.
Apart from arch code, where there are a bunch of people that do care given the obvious wide reach of changes, I've found that most subsystems that I pay attention do not have a "community" of developers to speak of & it is only those directly listed as maintainers who provide review - especially for new drivers etc.

@mupuf @ljs @marcan @jani

"Pinchart said that he always starts off a review by thanking the submitter for the patch and that he often offers a Reviewed-by tag if specific changes are made. That gives both a positive message and a hint of light at the end of the tunnel that can help new submitters."

Totally agree with Laurent on that one, especially if one is not an applier of patches for that code.
Interesting article, thanks for sharing.

@mupuf @jani @marcan @ljs @sima Out of curiosity, what do you mean by "the developers of the subsystem"?

@sima @gfxstrand @marcan @mupuf @ljs @sven please do! While I do get some smaller corners (like vendors who run their DT trees) having low rates, 25% seems shockingly low!

@llvm @marcan ohh that nails how I feel!

@marcan swap that around, "it often gets misunderstood, and I feel bad",

@marcan Oh yeah, that that *is* what I try to do. I try for something like "if for another reason you need to submit a vN, blah blah blah, otherwise looks good" etc, but I feel bad and it often gets misunderstood.

@marcan I'm not trying to defend any silliness, but I do at least understand why people make the comments at times.
In the non-mantainer case in particular, I often feel like there is "over-eagerness" involved too, and feel guilty of that myself at times as a non-maintainer reviewer of something. I suspect that there's a lot of heart in the right place involved without seeing the other side of it.

>At some point it's just time to let go because the experience for the submitter is just awful and it's not worth it.

Yup. I'm unimportant and in a small corner of the world, but probably worth seeing what can be improved in said corner.

@marcan

>To be clear, reasonable code quality comments aren't the problem, and helping out less experienced folks in a kind way is a tangential (but also important and frequently related) issue.

Yah, agreed. Especially the "frequently related" bit.
I was interpreting the "every new contributor has to build that list from scratch" with a bit of a focus on the "how to deal with them" bit & maybe I focused on that part too much as it kinda resonated with me. I just don't wanna be someone that people have to learn to deal with!

w.r.t the second paragraph:
I didn't think you were suggesting that people should take bad code. Sorry if it came across that way at all.
The alignment thing you suggested is a good example - I never know if I can or can't change that stuff in a patch that I add something, which is just silly.
Another one that I find silly is "that's not the right way to do x", without any hints as to what the right way might be. Certainly feel like the knowledge about how linux works is being gatekept in situations like that.

I've seen at least one of the interactions you're referring to (and probably can guess who the list.txt maintainer is).
One thing that is kinda frustrating is not knowing which maintainers are willing to fix up x, y or z on application and which want a respin for a $subject change.
Reviewing patches as a non-maintainer is a bit of an odd spot. If you don't mention some nit in v5 of a trivial driver, there's a chance noone spots it & if there's a v6 it'd not change. Not the end of the world I guess though most of the time.
I feel bad as said reviewer when someone re-submits to fix something that could likely be fixed on application, but not as if I can speak for the actual maintainer.

@marcan @ljs I've found everyone that I regularly interact with to be nice and/or helpful, but I've had plenty of "huh??" moments along the way.

@marcan @ljs

Airing grievances about maintainers aside, somewhere to check per-subsystem "quirks" would actually be helpful.
You've been around longer than I have, so I suppose you're aware of https://docs.kernel.org/process/maintainer-handbooks.html
although unfortunately that only covers two subsystems!
I guess in RISC-V land we also have https://docs.kernel.org/riscv/patch-acceptance.html that defines some constraints on submissions.

Creating a maintainer-handbook on someone's behalf seems a bit hostile, but perhaps having a list with "quirks" would encourage people to either drop or properly document them...

There's subsystems where the maintainer doesn't reply to patches, there's no git etc tree & the only way to know if something has been applied is when it shows up in -rc1!
If that confuses consistent contributors, documenting it for something like prolific like your apple-silicon stuff that, I assume, attracts new contributors seems helpful.