On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <spudan...@gmail.com> wrote:
> Sorry to keep running on... > > Another thing is that we do not want dictate to uses of release what > configuration management tools they must use. In our open source > culture, GIT is pervasive, but remember that many corporations prefer > commercial SCM systems. Case in point: My $company uses a really awesome SCM: Apache Subversion :-) So the process is something along these lines: (Please fill in any gaps...) Will we receive a patch, which I'm assuming will come to dev@ in the form of email attachments, then a NuttX committer looks at it, sees if it looks reasonable, then converts that into a GitHub PR. Which begs the question: how do we keep track of emailed patches being processed? Perhaps as simple as a committer replying to the email to say that it's being processed? Once at GitHub then automated tests run (including nxstyle), then ... ??? In certain parts of the system, I think we should have reasonably low barriers to getting contributions in. Drivers for adding, say, SPI support to some chip shouldn't require too much scrutiny provided they meet the coding standard... But: In some critical parts, including the build system and OS internals like the scheduler, we need a process whereby several pairs of eyes will look at the PR and agree that it should be merged. For example, say, we need N +1s and zero -1s for any changes that affect those parts... (the value of N will need discussion but that is a subject for another day). So, how will we keep track of approvals? I assume that GitHub has a built in mechanism for this purpose? Nathan
