This reads like a past slack discussion that ignored HW. Is that really what an embedded system OS should do?
> 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. One is a many to 1 relation. One is a 1 to 1. David -----Original Message----- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, December 19, 2019 10:33 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS - NuttX Workflow] >> I think only 5 emails in the whole list really address these functional >> requirements. > Let me add a 6th... (Without mentioning any "stupid" SCMs.) > > One thing missing from our earlier discussions is to decide how many > approvals a change requires. I think this varies by area of the code > being changed. > > As a starting point for further discussion, I suggest something along > these lines: > > Changes that affect the build system should require three +1 binding > votes and no vetoes from PMC members PLUS at least one report that > NuttX builds successfully on each supported platform: Windows, Mac, > Unix, and no reports of breakage caused by the change. Builds on > Windows using a Unix compatibility layer would be considered Unix for > this purpose. Any member of the community should be able to report > whether it builds successfully and on which platform. Between the > submitter of the patch, PMC members, and testers, this means that at > least 7 pairs of eyes looks at any change to the build system. This > high number is necessary because breakage there affects everyone and > is very disruptive! > > Changes to code that affect the core of the OS should require three +1 > binding votes and no vetoes from PMC members and should be accompanied > by some rationale or justification for the change. If applicable, > supporting data should be provided, e.g., if it's supposed to improve > performance, is this backed up by measurements? > > 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. > > In the apps repository: Changes to code in core apps (such as NSH) > should require two +1 binding votes and no vetoes. > > Changes to other non-core areas of apps are at the discretion of the > committer. > > Notwithstanding all of the above, there is the concept of an "obvious > fix." Any committer may fix things like obvious typos, misspellings, > grammar mistakes in comments, code formatting violations, that do not > change the behavior of the code, without the need for voting and > approvals, etc. Committers are expected to exercise their best > judgment here. > > It is expected that when someone votes +1 on a change, it means that: > > * They have studied the change > > * Verified that the change meets INVIOLABLES. > > * Verified that it does not break POSIX compatibility or OS > architectural boundaries > > * Done testing if feasible > > * Weighed any input from the community > > Please remember, the above are NOT rules, the above is a starting > point for discussion as we hash out our requirements. > > Please participate, offer your thoughts, criticisms, etc. > > Thanks, > Nathan Those sound like good rules of thumb to me. Certainly there are parts of the OS that require more care and have broader impact that others.
