On 2024-03-18 11:23, Krzysztof Kozlowski wrote:
On 17/03/2024 16:43, Justin Swartz wrote:
On 2024-03-17 17:29, Krzysztof Kozlowski wrote:
Objections to what? Coding style? Coding style is defined so you
either
implement it or not... and even if someone disagrees with one line
swap,
why it cannot be done like for every contribution: inline?
I had been asked to include empty lines when I had left them out when
I had contributed a patch regarding the serial nodes, which resulted
in
a second version of that patch.
I don't understand why would that matter. It's expected Linux
development process to receive comments inline in the patch.
Organize your patches how described in submitting patches: one per
logical change. Logical change is to reorder all properties in one
file,
without functional impact.
If I had accidentally deleted or modified an attribute in the process
of cleanup, this could have had a functional impact. It's easier to
How is it relevant? But you did not and splitting simple cleanup
one-line-per-patch is not affecting this. Just because you could make
mistake it does not affect patch readability at all.
Nothing improved with your patch split.
notice this sort of omission when the wall of text you're confronted
with is as small as possible, and not multiple pages long.
We are used to handle some length of patches. Multiple scrolls for
obvious cleanups are not problems. Why aren't you applying this
approach
to everything? Add a new driver with one function per patch and then
finally Makefile? It would be bisectable and "easy to read" plus
absolutely unmanageable.
But for future reference: is it not enough for the Reviewed-by:
trailer
to be sent in response to the cover letter of a patch set if a
reviewer
has looked at the entire set?
Sure, one can. I still need to open and download 14 patches.
Thanks for your input.
I can imagine how these sets of very minor changes might greatly reduce
your signal-to-noise ratio as an upstream maintainer.
I'll try your suggested approach next time.
