Message-ID: <eae79f9b-7127-6808-6a46-57ebc079ca50@manjaro.org>
Date: Tue, 07 Oct 2025 08:39:29 +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 Sunday, October 05, 2025 06:55 CEST, Rudraksha Gupta <guptarud@...il.com> wrote:
> > 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.
> 
> Awesome! I was hoping that others would comment on the testing I've done 
> (especially for the accelerometer and magnetometer patches) as I can't 
> tell if userspace is wrong or if my testing/conclusion is wrong. Mobile 
> Linux is very early stages at the moment, and I suspect the Pinephone 
> and Pinephone Pro were used as reference devices with Megi's downstream 
> kernel. Wrong mount matrices in the downstream kernel might be affecting 
> userspace. This means that with the corrected mount matrices in this 
> patch series, userspace is slightly broken (eg. since I fixed the 
> accelerometer, the screen in Phosh and KDE Plasma are upside down. I 
> suspect KDE's Kompass and Leonardo's compass app might be the same if 
> I'm changing the mount matrix for the magnetometer). This is why I 
> decided to showcase the raw values in my testing. If my testing is 
> incorrect, please feel free to let me know.
> 
> I think I will leave my testing in the commits itself this time. If the 
> mount matrices are correct based on my testing, it will probably be 
> helpful in the future in identifying why downstream is slightly broken.

I'll prepare and send to the mailing list a couple of patches that
will also adjust the mount-matrix values, so you might want to have
a look at those patch descriptions I'll prepare, as an inspiration
how could such information be presented in prose.

I'll also review your patches, to make sure that the mount-matrix
values are correct, hopefully around the end of this week, or next
week.  I'm having some issues with email, which I must resolve first.
(I'm actually hoping that this message won't come through as HTML,
as a result of those issues).

> > 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.
> 
> That's fair. I was under the assumption I had to keep the patches mostly 
> in its original form.
> 
> > 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.
> 
> At least with Gitlab & Codeberg, a lot of the notifications can be muted 
> (I believe updates to pull requests is one of them) and pipelines can be 
> created to ensure that formatting is correct and that the proper sub 
> maintainers are notified automagically. In my opinion, b4 just brings 
> some of the forge's functionalities into an email based workflow, but 
> will have to fight it's own problems such as: 
> https://social.kernel.org/notice/AypvdTWyAs5km0Gc3k. I don't mean to 
> detract from it; it is very commendable what Konstantin Ryabitsev is doing.

When it comes to submitting patches and their different versions,
reviewers have to be notified about each and every version, which
means that muting the notifications or ignoring some patch versions
simply isn't an option.  Even fully ignoring the patches that one
isn't interested in isn't a great option, despite sounding good,
because leaving out such parts makes one less insightful about
the subsystem they're contributing to.

Of course, the associated level of interest depends on one being
a "drive-by" contributor or being in for the long term, but for
the former different options exist to help with their periodic
contributions, such as the b4 or GitGitGadget.

You're right that the automagic features of forges may help with
setting up the lists of recipients and whatnot, but that's just
offloading of the complexity elsewhere, in hope that the automagic
part will work flawlessly, which is hardly the case with highly
complex projects, such as the Linux kernel. In other words, the
mailing-list based workflow does have its deficiencies, but it
leaves the contributors in full control, without relying on some
automagic things to do everything perfectly instead.

When it comes to formatting and whatnot, I'm sure you know that
there's already scripts/checkpatch.pl.

Powered by blists - more mailing lists