Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 18 Mar 2024 13:06:15 +0200 | From | Justin Swartz <> | Subject | Re: [PATCH 00/14] mips: dts: ralink: mt7621: improve DTS style |
| |
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.
| ![\](/images/icornerr.gif) |