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
