I agree that we should use both. Personally I like github PR since we can do code review and automated testing on PR With some manual work we can also handle patches as long as they apply clean and someone will spend the time to test them manually.
Regards Alin On Mon, Dec 16, 2019 at 12:56 PM David Sidrane <davi...@apache.org> wrote: > > 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 > > >
