[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <37f2603e-8c51-4f92-a7af-0e60cd577004@gmail.com>
Date: Sat, 4 Oct 2025 21:55:19 -0700
From: Rudraksha Gupta <guptarud@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
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 Dragan,
> 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.
> 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.
If there are concerns about centralization, there are alternatives like
Radical. I heard that Codeberg is looking to also decentralize in the
future as well (Maybe using Radical's protocol? Not sure). If there is a
call to action from the Linux maintainers about looking into
decentralized forges, I bet there would be many projects excited to be
used by the Linux kernel. It will also help get new people excited to be
involved in the Linux kernel and potentially become kernel maintainers
in the future
I think I will leave it at that, as I don't want to further derail the
conversation from the ppp series.
Rudraksha
Powered by blists - more mailing lists