Thank you Xiang!! :-) Would it be possible to support Lup's work too in this area? Lup saved our GitHub CI and has amazing results already with working prototype of independent distributed build and runtime testing :-) Tomek
On Thu, Jan 30, 2025 at 6:41 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > Ok, let's come up with a solid plan. Xiaomi could sponsor > engineering resources to improve the community automation test quality. > > On Thu, Jan 30, 2025 at 12:50 PM Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > That's true. So we should: > > > > 1. Decide if we want to have a LTS release, and > > > > 2. If yes, then we need to determine all the prerequisites. That will > > include things like the solid automation tests, and probably other things > > > > 3. Once we have defined what is needed, we can track the items in the issue > > tracker and start working to accomplish them. > > > > Of course, we can decide that LTS releases are not a good fit for us and > > improve the testing anyway. > > > > Cheers, > > Nathan > > > > On Wed, Jan 29, 2025 at 11:28 PM Xiang Xiao <xiaoxiang781...@gmail.com> > > wrote: > > > > > Before we have a solid automation test, how do we declare the release is > > > good enough to be LTS release? > > > As I mentioned before, it's impossible to have a stable base or LTS > > release > > > without enough automation test. > > > > > > On Thu, Jan 30, 2025 at 4:05 AM Nathan Hartman <hartman.nat...@gmail.com > > > > > > wrote: > > > > > > > On Wed, Jan 29, 2025 at 8:21 AM Alan C. Assis <acas...@gmail.com> > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > Yes, but it important to prove your point using a commercially > > > available > > > > > development board. > > > > > > > > > > NuttX (just like Linux) is a moving target. So one out of tree board > > > > always > > > > > will break because people are constantly changing the building system > > > and > > > > > moving things of place. > > > > > > > > > > There is no simple way to avoid this evolution. Unfortunately! So, > > > those > > > > > companies using NuttX could stick to a fixed release or use some > > > > automatic > > > > > patching process to detect issues early and report to us. > > > > > > > > > > BR, > > > > > > > > > > Alan > > > > > > > > > > > > The moving target does present a difficulty when trying to develop a > > > > product with NuttX that needs to be maintained and updated over time. > > > > > > > > There is a way to solve the moving target problem without limiting the > > > > speed of NuttX development: > > > > > > > > LTS Releases. > > > > > > > > Normal development can continue at full speed and new releases can be > > > > made every 3 months. > > > > > > > > But once in a while, such as every 2 years, we could make a LTS > > > > release. For this release, we would create a branch in the NuttX repo. > > > > After the LTS release is published, only bug fixes and security fixes > > > > can be backported to the LTS branch. We would keep each LTS release > > > > alive for 4 years. That means that in 4 years, we will deprecate the > > > > oldest LTS and publish a new LTS, and we will always have 2 active LTS > > > > lines. > > > > > > > > People who need stability can use the LTS line. If they need to add > > > > custom in-tree drivers or boards, they can base their private branch > > > > on the LTS branch. > > > > > > > > People who need faster development can work from master and the > > > > regular (non-LTS) releases. > > > > > > > > The time frame of 2 years and 4 years isn't set in stone. It's just an > > > > initial suggestion. > > > > > > > > Cheers, > > > > Nathan > > > > > > > > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
