+1 -----Original Message----- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Thursday, December 19, 2019 1:20 AM To: dev@nuttx.apache.org Subject: Re: Contributions (PR or patches)
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 > >>> > >> > >
