On Thu, Dec 19, 2019 at 8:30 AM Gregory Nutt <spudan...@gmail.com> wrote: > On Thu, Dec 19, 2019 at 3:32 AM Sebastien Lorquet <sebast...@lorquet.fr> > wrote: >> But the endless list of complex git commands with additional options is >> probably >> a blocker for many other people too. >> >> I dont even want to read it all. > > You and me both. The near term objective of the PPMC is just to come up > with a list -- maybe one page double spaced -- that just summarizes the > steps that changes will undergo going from a patch (or PR) to being > merged into master. Should be pretty simple. These would be the > "functional" requirements of the 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
