On Thu, Jan 30, 2025 at 1:42 AM Nathan Hartman <hartman.nat...@gmail.com> 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.

Hmm that sounds a bit complex already.. why not just keep things
self-compatible by design so if update breaks something then its not
here? :D

This way we may even not need the LTS.. or if really important the LTS
would serve as reference point.

This way more attention would be given to a long term maintenance
design in the first place.

Things will keep their standard interface, even if internals change,
or are optimized, or fixed, will produce repeatable results among
updates / releases.

In the "old theory" new features should not disrupt current standards,
so if something new shows up it must not destroy what is already
working. But there are "new theories".

To be honest I switched to BSD because of that self-incompatibility
called "bleeding edge innovation" (still problems happen here too).
Linux is a "moving target" and for this reason I avoid it - once you
write a driver, yes kernel api changes every minor release, yes you
need to maintain that piece of code forever, yes it is you who is
responsible to follow what changed and how and how to fix it. Kind of
situation Sebastien describes. Unfortunately standard in Open-Source
nowadays, even worse in closed-source tools, look at mobiles. I hope
this will never happen in NuttX "by design" and we will stick to
self-compatibility. Current situation may be result of lack of
adequate detailed build and runtime testing and also here is the
solution I suppose.

For instance if Sebastien had his board attached to local CI machine
that builds and runs the master all the time it would be really easy
and quick to catch possible problems and fix them right away not after
one year. It may be even possible to catch commits from PRs and react
to changes before these are merged! This is how I see distributed
build and runtime :-)

Have a good day folks :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Reply via email to