I want to make a Pull Request to fix an issue in the V10.4.3-LTS-Patch-3 release. Because without this issue it is not possible to compile FreeRTOS with the POSIX port.
Create a fork and fixed the bug (cherry picked a commit that fixed the bug): see /conara/FreeRTOS-Kernel/tree/V10.4.3-LTS-Patch-3-fix-bug (cannot post links)
Tried to create a Pull Request. Changed the “base” from “main” branch to “V10.4.3-LTS-Patch-3” tag, but in that chase the pull request window disappears.
Is it necessary to create a V10.4.3-LTS-Patch-4 branch first? Or what is the workflow for this? I hope somebody can help me with this.
Thank you for reporting this issue. We are aware of this and we did not include it in LTS patch knowingly. As per the definition of LTS described here, we provide security and critical bug fixes for our LTS release. In order to keep the LTS stable and minimize the number of patches, we keep the bar very high when deciding issues to include in the LTS patches. This issue, unfortunately, does not qualify as a candidate for an LTS patch, especially as the POSIX port is not used in production devices. As a result, you will need to remove the unnecessary asterisk in your clone. Thank you once again for your time.
Thanks for responding! In my opinion this is a critical bug, because it makes the POSIX target useless (unless we patch it manually). We are relying on the LTS release for our production software, but we also have a simulator target for our software to test our software. I understand that you want to keep the changes as minimal as possible, but this is very unfortunate.
But I understand you have no intention of adjusting it, so we’ll work around it.
Our preferred path (for non-security related issues) is to discuss them here first, after which you/we can open a github bug issue once there is consensus it is a bug. That is because many reported bugs turn out to be configuration or usage issues, which can devalue the bug list for users.
To add Gaurav’s post above - defining what constitutes a critical bug is subjective. What is critical for one user isn’t for another. In the POSIX port case it isn’t classed as critical because there is an easy workaround (i.e. deleting the offending character) and doesn’t impact the run-time behaviour.