I'm happy to see things done right in the form of mainlining the necessary parts, but that takes _years_. Users shouldn't have to suffer with known security issues that have fixes readily available.
I've used this tool to support many dozens of end-of-life devices working well over the past six years, and it is even purpose-built for these Android/Qualcomm downstream kernels.
Maybe you could rework your process a bit, as a drive-by patchset with 400+ commits is not a great way to start a conversation. Some ideas:
- Open an issue or post to the project's mailing list, proposing the use of your tool.
- If you don't do so already, have your tool only apply patches to code that is actually compiled for the target, e.g. give it a .config and trace which source files are used in make.
- Obtain the hardware for the devices your tool supports and donate your time to test the changes generated by your tool.
Only applying patches that may be necessary is absolutely non-trivial to compute, especially with dependent patchsets, kernel trees used by multiple devices, or future changes to their configs.
I already provide monthly software updates for 170 devices using this tool which I've personally tested on two dozen devices plus many user reports on others. Making a (near) working PR conversation starter to demonstrate the tool I've spent years of my time on is my contribution.
In this case where I didn't have a PinePhone I explicitly found a closest match (Google Pixel 1/marlin iirc) to the kernel at hand and applied my fix database to it as matching to increase the chance that it would be successful.
I have absolutely zero doubts that someone can't apply the PR and be up and running in an hour.
edit: to be extra clear, I'm not a company selling this tool or anything, it is purely a passion project for me and I do want others to use it or help them use it.
I'm happy to see things done right in the form of mainlining the necessary parts, but that takes _years_. Users shouldn't have to suffer with known security issues that have fixes readily available.
I've used this tool to support many dozens of end-of-life devices working well over the past six years, and it is even purpose-built for these Android/Qualcomm downstream kernels.
Maybe you could rework your process a bit, as a drive-by patchset with 400+ commits is not a great way to start a conversation. Some ideas:
- Open an issue or post to the project's mailing list, proposing the use of your tool.
- If you don't do so already, have your tool only apply patches to code that is actually compiled for the target, e.g. give it a .config and trace which source files are used in make.
- Obtain the hardware for the devices your tool supports and donate your time to test the changes generated by your tool.
Only applying patches that may be necessary is absolutely non-trivial to compute, especially with dependent patchsets, kernel trees used by multiple devices, or future changes to their configs.
I already provide monthly software updates for 170 devices using this tool which I've personally tested on two dozen devices plus many user reports on others. Making a (near) working PR conversation starter to demonstrate the tool I've spent years of my time on is my contribution.
In this case where I didn't have a PinePhone I explicitly found a closest match (Google Pixel 1/marlin iirc) to the kernel at hand and applied my fix database to it as matching to increase the chance that it would be successful.
I have absolutely zero doubts that someone can't apply the PR and be up and running in an hour.
edit: to be extra clear, I'm not a company selling this tool or anything, it is purely a passion project for me and I do want others to use it or help them use it.