It would be really nice if we could get all patch series to go into PRs, even if we don't have the QA and everything setup yet. I would be happy to automate that via something like patchwork if that is of any help.
--Brennan On Thu, Dec 19, 2019, 12:56 AM Flavio Junqueira <f...@apache.org> wrote: > 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 > >>> > >> > >
