Patches through the email list are acceptable [1]. It is harder to track issues and implement an effective workflow (e.g., running QA builds, code reviews) for contributions via the list, but from a legal standpoint, it is acceptable.
-Flavio [1] https://www.apache.org/foundation/how-it-works/legal.html <https://www.apache.org/foundation/how-it-works/legal.html> > On 19 Dec 2019, at 09:15, Alin Jerpelea <jerpe...@gmail.com> wrote: > > 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 >>> >>
