Things are a bit different in ASF as we can use jenkins instead of travis ci.
If the code is ready on github, I could help setting up the jenkins job to pull PR as I've done this for other ASF projects in the past. Thanks. Xiang Xiao <xiaoxiang781...@gmail.com> 于2019年12月16日周一 上午11:35写道： > 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 >
