> So, how will we keep track of approvals? I assume that GitHub has a built in mechanism for this purpose?
Nathan, Yes it if built for this and from my perspective working on a 93 person team, with 67 repositories. It is highly efficient, collaborative, and effective. For example: Ignoring the excellent process integration to create a proper work flow that keeps master clean and building with full CI integration. Have a look Suggested changes: Suppose you’re collaborating on a repository with an active pull request. A reviewer can look at that pull request, and if they see room for improvement, suggest a change to the code by leaving a comment. The author can then accept the suggestion with a single click. DRAFT PR. You want input on a design. Create a draft PR, get all the input and value add the community has to offer. That will not be merged before it is ready. Here is the value I see in this from past experiences: I have had multiple ways to solve a problem and wanted to get the collective expert's feed back. I Put up a PR for discussion marking it a Work In Progress [WIP] and the next thing I know, my WIP was merged. >From my perspective patches, unless applied to a branch do not offer a >collaborative resolution method- nor do they provide a way to educate the >community, without an undo effort to decode the delta for the contributed >patch to what was applied (speaking of the past process). Let's get some requirements defined, our goals laid out and then discuss the pros and cons of the options for workflow and the tools that exits the make the whole of the PPMC productive. I am reflecting on statements like, "Volunteers with full time jobs" and "Simple for users." We owe it to ourselves and the community to make this efficient and effective. David On 2019/12/16 03:35:01, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > Yes, GitHub has the standard workflow, we just need insert our special > requirement(style, build and test) into it: > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow > Here is one example mynewt: > https://github.com/apache/mynewt-core/pull/2126 > > Thanks > Xiang > On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman > <hartman.nat...@gmail.com> wrote: > > > > 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 >
