Conversation
@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.
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.
1
0
2
@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.
"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.
0
0
1
@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.
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.
0
0
2
@marcan @ljs
You call the requirements arbitrary or silly, I'll give you my perspective:
> "put your declarations in reverse Christmas tree order"
I'm not a fan of the reverse xmas tree, but such local coding style preferences are there for consistency for those who have to read the code base, lots of code is read en bloc and pattern recognition becomes a great help to skim a lot of code; the drawback is that it mandates new code in that specific format, ideally documented somewhere, but practical advice is to mimic the style in the same file however unusual it may feel.
> "always do minimal fixes, ...
As linux cares about backports to old stable kernels a minimal fix has a much higher chance to get applied without merge conflicts and there's a scripting machinery around that to minimize manual fixups be people only when necessary, fixing more bugs in one patch should be avoided unless it would be really awkward so it's a gray area but in general one fix per patch should be the default, what makes sense or not is subjective and opnions differ, in the end it's the maintainer who has to deal with the fallouts of that.
> "do not reformat code to keep alignment after changes, ...
Similar argument as above, for easier backports, but it depends on the change. Patches just fixing coding style should be avoided as it clutters git history and fixing coding style issues in the modified lines should be ok but not fixing surrounding code just because it's in the same file.
What you complain about is nothing new and I've had this discussions with several people over the years. Unfortunatelly documenting the practices also does not work, nobody reads that so it always starts with the first patch and customized 1:1 response.
Frequent contributors should know how to do it (but often they don't) and I personally cut a lot of slack in one-time contributions and fix a lot of things myself when committing patches.
You call the requirements arbitrary or silly, I'll give you my perspective:
> "put your declarations in reverse Christmas tree order"
I'm not a fan of the reverse xmas tree, but such local coding style preferences are there for consistency for those who have to read the code base, lots of code is read en bloc and pattern recognition becomes a great help to skim a lot of code; the drawback is that it mandates new code in that specific format, ideally documented somewhere, but practical advice is to mimic the style in the same file however unusual it may feel.
> "always do minimal fixes, ...
As linux cares about backports to old stable kernels a minimal fix has a much higher chance to get applied without merge conflicts and there's a scripting machinery around that to minimize manual fixups be people only when necessary, fixing more bugs in one patch should be avoided unless it would be really awkward so it's a gray area but in general one fix per patch should be the default, what makes sense or not is subjective and opnions differ, in the end it's the maintainer who has to deal with the fallouts of that.
> "do not reformat code to keep alignment after changes, ...
Similar argument as above, for easier backports, but it depends on the change. Patches just fixing coding style should be avoided as it clutters git history and fixing coding style issues in the modified lines should be ok but not fixing surrounding code just because it's in the same file.
What you complain about is nothing new and I've had this discussions with several people over the years. Unfortunatelly documenting the practices also does not work, nobody reads that so it always starts with the first patch and customized 1:1 response.
Frequent contributors should know how to do it (but often they don't) and I personally cut a lot of slack in one-time contributions and fix a lot of things myself when committing patches.
0
0
2