> Quite the opposite :-) Testing few boards multiple times in the same by different people may be a bit of waste, but its more about anyone providing what they have at hand and I am sure different people from around the world will have different boards, more people more boards coverage, and we will verify different boards configuration in real world :-)
NOPE. Many boards are just copy-paste of other boards. Most stm32 boards look like this. Chips with the same architecture use the same code, so when we test a more advanced chip, we also test the code for a less advanced chip. The flaw in your reasoning is that we don't have many people around the world, just a few, and even fewer, who are willing to get involved in this project :) Another thing is that some of the boards are obsolete and impossible to get. Testing everything as a final goal is OK, but right now it's a waste of resources. I think it's much more productive to select the minimum number of boards that give the greatest coverage for the code. > It seems it is already spread over many various emails and github issues. I think emails are good for discussions, while github is good for noting conclusions down. But if you like Confluence we may try it why not :-) This is exactly the problem with email. This is not the first time these topics are discussed. Similar discussions and ideas have already been here. Where are they now? Somewhere in dozens of emails over the years that I can't even find. Email for discussion and decision-making - OK, email as a knowledge base and an organized place with content - not really. czw., 6 lut 2025 o 04:09 Tomek CEDRO <to...@cedro.info> napisał(a): > On Wed, Feb 5, 2025 at 8:25 AM raiden00pl <raiden0...@gmail.com> wrote: > > But first we should determine what things we want to test, not what > boards. > > Knowing what things we want to test, we can design test cases and > possibly > > use what is already available. > > This will be part of the drunx architecture, but I have created a > dedicated Issue just for DRUNX Test Scenarios :-) > > https://github.com/apache/nuttx/issues/15773 > > Thanks! :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
