Hi Nathan, You Rock!
On 2019/12/20 05:31:37, Nathan Hartman <hartman.nat...@gmail.com> wrote: > 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. > Right! Boards are secondary - your itch, your blood if you scratch it wrong. > As for protecting the OS's reputation, I think that each board should > have some sort of "Status" score: > Yes! +(1.0/0.0) more then 18billion :) > * 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. > We build this - and give it to the world for free. http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/master/1142/pipeline You also _give_ them the design files (BOM,etc) to build this: https://docs.google.com/spreadsheets/d/1EdbT_deF-nqZ5bysBFqwQLaOa1irG3gsgE6za5GKap4/edit?folder=1cUEhrAQh-72D5Sgy5sRmXpoTqwqj6A1D#gid=0&range=1:1 Then we write real test. For each driver and build configs with them. The rest will fall into place. > 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. Then you and your company will want one of these! > > 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. > I do not agree on this : To translate to ASF lingo: One to many meant that: Very skilled contributors while scratching their own itch can make others itch's bleed is ways they do not realize. This is the same pattern that cases rejection of contribution to the OS. "Myoptic" is the word Greg will use. What is good for the OS is good for the Project as a whole - as stated by Greg on the not vaporized Slack: He does not care about hardware. It is not interesting to to him. His goal is making a perfect operating system. I will call it "world class" using best practices in both design and implementation. Out goal as a community should be using best practices in both design and implementation of the PROJECT - the code, the tooling, the build system, test and HW support. We should ask the 395 - if there was no hardware support: Would you use NuttX? > Thoughts? > > Cheers, > Nathan > David
