On Thu, Dec 19, 2019 at 4:40 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > Changes to code in MCU architectural support, board support, or features > > in the periphery of the OS should be at the discretion of the > > committer. Committers should use their best judgment and are > > encouraged to discuss anything they're not sure about. But these > > changes don't require as much oversight. These changes are much more > > limited in their exposure. They are usually developed by someone to > > scratch their own itch. Also these are allowed to be feature- > > incomplete: e.g., it is okay to have partial board support. > > I do not agree. MCU and board changes need better scrutiny for many reasons, > here are some: > > 1) Proper patterns applied. This gets misses a lot - consider the "ifdef > rash" and missed invilotes > 2) Proper scoping - this just happened in imxrt > 3) They still can break the build. > 3) They still can ruin the OS's reputation. > 4) This is where HW background is needed. > > You may want to consider separate levels of scrutiny for MCU's than boards.
Acknowledged. The issue with boards and MCUs is that the pool of contributors for these areas is much thinner than the pool of contributors for some of the more heavily exercised areas. Now, I can see where a company that produces a board -- and wants to provide full NuttX support for it in order to sell those boards -- could pay engineers to develop FULL tested and characterized support for the board and all its features. But, if it's a volunteer like me, I would likely implement support for the parts I'm going to use. It's a "scratch your own itch" type of development. Although this is "incomplete," I would greatly prefer to have it contributed to NuttX, over rejecting it due to incompleteness, because it reduces effort for the next person who wants to use that board, even if they need to implement support for a missing feature. It's better to start with partial support and implement the extra part you need, then to start from zero. Now, I agree that we need to check for proper patterns, proper scoping, and unbroken build. But we can't necessarily have PMC members testing changes to boards because they may not have the board. Also, testing changes may require a whole hardware test setup with oscilloscope / logic analyzer and we cannot expect PMC members to spend that much time testing a change. It will never get voted on and people will become discouraged and stop contributing. So, we must have a certain amount of trust that the person contributing changes is doing so in good faith. Perhaps we need a PMC vote, or, say, two non- PMC committers to agree that changes to board support follow the code conventions and rules, but their +1 doesn't have to imply that they have the hardware and actually tested the change. As long as it follows basic rules and seems legit, it should be committed. As for protecting the OS's reputation, I think that each board should have some sort of "Status" score: * Boards with complete support that are widely exercised and known to work correctly out of the box could be given a "Tier 1" status. Recommended if you just want to focus on your application and have all the hardware details taken care of for you. * Boards with less support and testing could be categorized as "Tier 2" status, meaning that NuttX's support for them might be fine for some applications but some board features may be unsupported, incomplete, or not well-exercised. Recommended for the hardware savvy who don't mind if they have to fix a few issues to finish their project. * "Tier 3" could mean implementation in progress and many features are missing or buggy. Recommended for those who want to hack on support for the board. How to arrive at such a status score? This could be problematic, since not all of us own every single board in NuttX, and even if we did, we could never volunteer the time that it would take to characterize and test every board and all its features with NuttX. So we may have to rely on the word of the implementer and community members who happen to use a particular board, or we could consider factors like the number of contributors who have worked on a board, the number of bugs reported, the number of bugs fixed, time between report and fix, and word of mouth from the community. Just a thought. Regarding boards, I'd like to point out that at my job, all boards are custom boards designed by us. So it is entirely up to us to support a board. I am guessing that most companies that produce products with NuttX are doing so with custom boards anyway. I don't think they're incorporating LaunchPads or Nucleo boards into commercial products. But that's just my guess. As far as MCUs go, we could do something similar with "Tiers" (or other terminology, if you prefer). MCUs might be more heavily exercised than boards, because the same (or similar) MCU may appear on several different boards. Also MCUs in the same family tend to share many common themes with just minor differences. I believe that the NuttX website already contains some documentation about the caveats of various MCUs. Again, because the pool of contributors for a particular MCU family may be thinner than for other parts of the system, we may have to check that basics like coding standard are followed, but +1 doesn't have to imply that you have the MCU and conducted in-depth tests before you voted. Again, if the change seems legit and the coding rules are followed, we will have to trust that changes are contributed in good faith. Thoughts? Cheers, Nathan
