Hi!
LTS releases is a good idea as such, but the underlying problem which
Sebastien is (sort of..) pointing out needs to be addressed somehow also
in the mainline.
I get frustrated as well, from time to time, with a huge amount of
unnecessary commits being pushed in, very quickly. I will just give one
example here (I don't want to blame anyone specifically, this is just
one example!)
For the SMP work, lot of critical sections have been changed to
spinlocks. This is good! What is bad is, that this has been done also
for the platforms *which are single core and can't have SMP!*.
And even worse, the changes have been done to the HW drivers without
testing the code at all!
See for example this PR:
https://github.com/apache/nuttx/pull/15317
Which was broken (obviously not tested on all the platforms it
touched!), and which Chao An (thanks!) needed to patch later in
https://github.com/apache/nuttx/pull/15517
The change of critical sections to spinlocks for non-smp targets just
does two things:
- Increases memory consumption (the spinlock needs to be allocated)
- Adds risk of deadlocking! The critical sections can be nested,
spinlocks not.
And it doesn't add *any* value.
Touching the HW drivers / platform code should only happen for good
reason! There are many many changes in the "arch" which have no reason
whatsoever! You don't tamper with tested HW drivers just to make it look
better, and definitely don't tamper with those without testing *each*
driver which was changed.
Another thing is the build system; don't make unnecessary changes to the
build system. If your downstream project needs something different from
the build system than what the upstream project provides, it is NOT OK
to just quickly push in all the possible changes to the build system
from your downstream project. This *will* break ever other's downstream
project builds. Every change to the build scripts should be carefully
reviewed, whether it serves the *upstream* Apache NuttX or noṭ...
And again, I don't want to blame anyone. And especially I am not
pointing the developers providing the PR:s! It is valuable work to
provide the patches to the upstream. But for the maintainers approving
the PR:s, a bit more careful approach is needed!
- Are all the changed code lines covered in tests? If not, why not, and
is there some real critical reason to still merge? How to manage testing
of those after merge if not tested before?
In bigger projects (like linux), it is of course a bit easier since
every component has a named maintainer, who needs to approve the change.
This is probably not possible here..
Just my 2 cents for this discussion,
-Jukka
On 30.1.2025 2.42, Nathan Hartman wrote:
On Wed, Jan 29, 2025 at 3:40 PM Alin Jerpelea <jerpe...@gmail.com> wrote:
LTS is a good idea the only issue is that we can not guarranty that the
patches can be backported for 2 years due to the way PRs are submitted.
most time a change is affecting multiple drivers or subsistems instead of
having separate smaller PRs.
We will need to improve guidelines and do PR screening.
I recognize this issue -- if a backport doesn't merge cleanly to the
LTS release's branch, we can create a backport branch (based on the
LTS release's branch), cherrypick the backport from master onto that
backport branch, fix the merge conflicts manually, and then merge it
cleanly to the LTS release branch. It's an added step, but it allows
us to maintain LTS for several years.
Alternatively...
I propose that each year the Q1 release becomes LTS for 1 year then gets
only security fixes for the second year while a new LTS is maintained.
...this is a reasonable starting point as well. If I understand
correctly, this means 1st year bugfixes + security fixes, 2nd year
security fixes only. After that, the release is EOL.
We can try that, and gather feedback. It's possible that people will
want longer LTS, but it's also possible that this will be good enough.
Cheers,
Nathan
