Message-ID: <115da845d9161e6ecfa67cf189b84aa8@manjaro.org>
Date: Mon, 29 Sep 2025 10:20:08 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Rudraksha Gupta <guptarud@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, Ondrej
 Jirman <megi@....cz>, "Leonardo G. Trombetta" <lgtrombetta@....com>
Subject: Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

Hello Rudraksha,

On 2025-09-29 09:44, Rudraksha Gupta wrote:
>> Thanks for submitting these patches.  However, please expand the patch
>> descriptions, because their current forms are too terse and, as such,
>> simply not acceptable.  This applies to all patches in this series.
> 
> Gotcha, will do! I've added the testing that I did. From
> https://docs.kernel.org/process/submitting-patches.html
> 
>> The text should be written in such detail so that when read weeks,
>> months or even years later, it can give the reader the needed details
>> to grasp the reasoning for why the patch was created.
> 
> It felt like saying more than "adding x sensor" seemed like adding
> fluff to me, so that is why I kept it short. Let me know if there is
> something else I should add beside the tests I have done.

Thanks for improving the patch descriptions in the v4 of this series.
I just went quickly through the v4 and it looks much better.

It could be said that the new patch descriptions are now a bit too
verbose, in the sense that the test procedures and their results could
be summed up a bit better in prose, instead of providing the "raw"
inputs and outputs.  However, it's still better to have those, than
not to have anything.  Writing good prose is a skill that usually
requires learning and practice.

>> I'm also under impression that you're submitting these patches 
>> upstream
>> blindly and without researching the rules that apply well enough, 
>> which
>> may not be the best possible approach.
> 
> Sorry! I've read
> https://docs.kernel.org/process/submitting-patches.html a bunch of
> times during the years I have contributed to the Linux kernel and
> inevitably forget something. Please feel free to tell me what I've
> done wrong! I've corrected my mistakes in v4 (and undoubtedly probably
> introduced more, but feel free to tell me that ;) )

You haven't done anything technically wrong, but the way you submitted
the v2 and v3 made them feel a bit like you picked those patches from
some random place and submitted them to the mailing list without really
understanding the subject matter.  In other words, it's the 
contributor's
job to convince everyone else that the submitted patches are fine to
become accepted, and the v2 and v3 simply lacked that.

>> Finally, please refrain yourself from sending multiple versions of the
>> same patch series in the same day.  Doing so makes reviewing the 
>> patches
>> unnecessarily hard.
> 
> Sorry about that once again! I'm mostly a hobbyist that loves working
> on Linux over the weekend. I wanted to get correct my mistakes so that
> I can get reviews over the week. I wish lkml used a forge, so I didn't
> have to spam you, but I digress. I will keep this in mind moving
> forward.

I wonder how would some forge prevent "spamming"?  It isn't about the
possible "spamming", but about the act of submitting different versions,
which would be present regardless of the way they'd be submitted, and
the reviewers would need to be aware (i.e. "spammed") of them anyway.

Powered by blists - more mailing lists