Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rudraksha Gupta <guptarud@gmail.com>]

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