Hi! First thing, I'm fairly new to nuttx so I might be off subject but here is my hot take on this subject.
NuttX is offering support for a lot of boards, more than what DRUNX should require. Eg. stm32f3 family, offering support for all the boards would benefit the boards more than the NuttX codebase. These boards share 80% of the code but each in its own files, so most differences are due to lack of backporting. My suggestion is to take a single board for each mcu family as mandatory NuttX support, others as optional. I'm not saying to drop support, or offer less support for those, just to treat the mandatory as higher prio. For the moment we can choose what is mandatory, and at a later time, when DRUNX would be stable, move the optional ones to DRUNX repo (for example). TLDR: I think less is more, less "official" support, more "official" coverage. Have a great day! Mihai On Tue, 4 Feb 2025 at 10:25, Tomek CEDRO <to...@cedro.info> wrote: > Hello world :-) > > Lets keep the distributed build and runtime test environment > discussion in this mailing list thread. > > Here is the discussion issue on GitHub: > > https://github.com/apache/nuttx/issues/15730 > > > Some things for start, at this point in time: > > 1. If anyone has better working name please share :-) > > 2. Lup created nice dashboard for gathering and presentation in one place: > > https://nuttx-dashboard.org/ > > This platform gather logs from builds that use the same scripts as CI > on GitHub runs. We had the CI overuse problems on GitHub and risk of > loosing CI, thus this solution as backup. > > We can extend it with runtime tests. That part is still TODO. PyTest > seems the best and commonly used framework. This can launch sets of > tests like build, run, gather logs, upload somewhere for analysis > (gist -> dashboard). > > 3. We need to select a set of standard tests to be processed runtime. > ostest and some benchmarks / stress tests. In a pefcest situation. We > are working on apps/testing rework to split into apps/system > applications, apps/testing utilities, and apps/tests scenarios that > could run on MCU and do the tests with PASS/FAIL result list. > > 4. This solution should be based on zero-trust approach. That is > upstream does not trust user testing, but we provide tools to run > tests and report back results that would prove changes are not > breaking stuff. > > 5. Not to create more mess in the nuttx repo I have created a > dedicated workbench repo nuttx-drunx that we may work on and if > something is ready we will send to nuttx upstream: > > https://github.com/cederom/nuttx-drunx > > Thank you :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
