You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Anthony Merlino <an...@vergeaero.com> on 2019/12/16 01:31:24 UTC
Contributions (PR or patches)
As Nathan and others have pointed out, we need to discuss, agree, and
document how we would like to accept contributions.
I think at most, we should accept patches on the mailing list, and PRs on
GitHub. But personally, I think we should only support PRs. I think a
unified method for all contributions is desirable and makes the PPMC's
lives easier. PRs require less work from committers, and tie into the
automated build tools easier. They are way easier to keep track of too -
Github just lists them all for us. They also can be reviewed and merged
without leaving the browser, assuming the change is valid and the build
testing has coverage.
What do you think?
Best,
Anthony
Re: Contributions (PR or patches)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Things are a bit different in ASF as we can use jenkins instead of travis ci.
Other CIs are available, but jenkins is probably he most widely used one.
Thanks,
Justin
Re: Contributions (PR or patches)
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <xi...@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
> <ha...@gmail.com> wrote:
> >
> > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
>
RE: Contributions (PR or patches)
Posted by David Sidrane <Da...@nscdg.com>.
+1
-----Original Message-----
From: Brennan Ashton [mailto:bashton@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 <fp...@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 <je...@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 <da...@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 <xi...@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
> >>> <ha...@gmail.com> wrote:
> >>>>
> >>>> On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
> >>>
> >>
>
>
Re: Contributions (PR or patches)
Posted by Brennan Ashton <ba...@brennanashton.com>.
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 <fp...@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 <je...@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 <da...@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 <xi...@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
> >>> <ha...@gmail.com> wrote:
> >>>>
> >>>> On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
> >>>
> >>
>
>
Re: Contributions (PR or patches)
Posted by Flavio Junqueira <fp...@apache.org>.
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 <je...@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 <da...@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 <xi...@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
>>> <ha...@gmail.com> wrote:
>>>>
>>>> On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
>>>
>>
Re: Contributions (PR or patches)
Posted by Alin Jerpelea <je...@gmail.com>.
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 <da...@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 <xi...@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
> > <ha...@gmail.com> wrote:
> > >
> > > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
> >
>
Re: Contributions (PR or patches)
Posted by David Sidrane <da...@apache.org>.
> 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 <xi...@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
> <ha...@gmail.com> wrote:
> >
> > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
>
Re: Contributions (PR or patches)
Posted by Xiang Xiao <xi...@gmail.com>.
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
<ha...@gmail.com> wrote:
>
> On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
Patches against Releases? (Was Re: Contributions (PR or patches))
Posted by Gregory Nutt <sp...@gmail.com>.
>> 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.
>
> Or would we take PRs. PRs would, mostly likely, be directly against
> the master. Is that an issue?
>
> Would we merge patches onto master? Or onto a development branch?
> What would be do with PRs against master?
>
> One problem with patches is the they have dependencies. Applying one
> patch, may cause a subsequent patch that affects the same file to fail
> to apply. The solution would be to put each patch on a branch so that
> it can be merged back in without conflicts (or at least with conflicts
> that can be resolved with GIT help).
>
> We need to spell out the branching.
>
Here is a follow-on question. We have not addressed releases yet, but I
assume that we will be making releases on branches. This offers us
another opportunity to make life easier for NuttX users too (which
should always be one or our primary objectives in all things):
Most businesses will use the GIT-less release versions and will avoid
code du jour. When they fix bugs or add features, the changes will be
against the release versions not the current GIT HEAD. In the past, I
have asked people who submit patches against a release to update the
patch so that it applies to the current HEAD. I imagine that this is an
onerous task if you don't use GIT at all.
Wouldn't it be better for such users to be able to accept patches
against releases too? These might have to be applied to branches off of
the release branch, but could still be cherry-picked back to master if
they check out.
This is not a critical issue now. Let's deal with the more important
organizational issues at hand, but tuck this this idea away for
consideration later when we fully refine the workflow.
Greg
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
> Case in point: My $company uses a really awesome SCM: Apache Subversion :-)
All very large corporations I have worked for use commercial SCM
suites. GIT is a great thing for open source projects and small
businesses, but for those companies with essentially unlimited resources
you will often see very different commercial tools .. and also RTOSs 8(
> 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.
Or would we take PRs. PRs would, mostly likely, be directly against the
master. Is that an issue?
Would we merge patches onto master? Or onto a development branch? What
would be do with PRs against master?
One problem with patches is the they have dependencies. Applying one
patch, may cause a subsequent patch that affects the same file to fail
to apply. The solution would be to put each patch on a branch so that
it can be merged back in without conflicts (or at least with conflicts
that can be resolved with GIT help).
We need to spell out the branching.
> 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?
Is Jira an option?
> 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).
+1
Changes to "leaf" software can not create widespread problems but still
need to be taken seriously.
Greg
Re: Contributions (PR or patches)
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt <sp...@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
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
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. I don't think anything about the usage case of
NuttX should depend upon particular tools in the user environment (other
than those minimal tools necessary for the build).
Forcing GIT on everyone would lose some users.
Greg
On 12/15/2019 7:48 PM, Gregory Nutt wrote:
> Just a guess, but I think right now we receive 50 or so patches for
> each PR. That is very deeply ingrained in NuttX userland.
>
> On 12/15/2019 7:45 PM, Gregory Nutt wrote:
>>
>>> I am just wondering if we are excluding any users by forcing
>>> everyone to use PRs. I personally don't have problems with mixed
>>> PRs and patches, provided that the patches apply clean. I think we
>>> should take the side of the lowest common denominator user and NOT
>>> the point of view that makes our job the slickest.
>>>
>> Remember that the majority of NuttX users do not use git at all. They
>> use the release tarballs which have all GIT information stripped
>> out. No GIT and not GIT knowledge is required to use NuttX. I don't
>> know if it is customary to strip GIT out of Apache tarballs, but
>> still we need to accept users that have no GIT skills.
>>
>> It is one of the core principles of NuttX that "all users matter" and
>> that we do nothing to restrict the use of the OS, especially not to
>> make out internal life simpler at the expense of a world of users.
>> We should do the opposite; we should keep the complexit o y inside
>> the project and do all we can to make NuttX accessible to all users.
>>
>> Greg
>>
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
> But I think that someone from committer need convert patch to the
> github pull request, and then pass all automatic check before
> submitting the change.
> To ensure the commit quality, nobody can bypass the workflow we will setup.
You are absolutely right. There is not difference between accepting a
patch vs a PR is that the patch must be applied and committed. After
that, it does not matter how the commit got there.
Re: Contributions (PR or patches)
Posted by Xiang Xiao <xi...@gmail.com>.
But I think that someone from committer need convert patch to the
github pull request, and then pass all automatic check before
submitting the change.
To ensure the commit quality, nobody can bypass the workflow we will setup.
On Mon, Dec 16, 2019 at 9:48 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> Just a guess, but I think right now we receive 50 or so patches for each
> PR. That is very deeply ingrained in NuttX userland.
>
> On 12/15/2019 7:45 PM, Gregory Nutt wrote:
> >
> >> I am just wondering if we are excluding any users by forcing everyone
> >> to use PRs. I personally don't have problems with mixed PRs and
> >> patches, provided that the patches apply clean. I think we should
> >> take the side of the lowest common denominator user and NOT the point
> >> of view that makes our job the slickest.
> >>
> > Remember that the majority of NuttX users do not use git at all. They
> > use the release tarballs which have all GIT information stripped out.
> > No GIT and not GIT knowledge is required to use NuttX. I don't know
> > if it is customary to strip GIT out of Apache tarballs, but still we
> > need to accept users that have no GIT skills.
> >
> > It is one of the core principles of NuttX that "all users matter" and
> > that we do nothing to restrict the use of the OS, especially not to
> > make out internal life simpler at the expense of a world of users. We
> > should do the opposite; we should keep the complexit o y inside the
> > project and do all we can to make NuttX accessible to all users.
> >
> > Greg
> >
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
Just a guess, but I think right now we receive 50 or so patches for each
PR. That is very deeply ingrained in NuttX userland.
On 12/15/2019 7:45 PM, Gregory Nutt wrote:
>
>> I am just wondering if we are excluding any users by forcing everyone
>> to use PRs. I personally don't have problems with mixed PRs and
>> patches, provided that the patches apply clean. I think we should
>> take the side of the lowest common denominator user and NOT the point
>> of view that makes our job the slickest.
>>
> Remember that the majority of NuttX users do not use git at all. They
> use the release tarballs which have all GIT information stripped out.
> No GIT and not GIT knowledge is required to use NuttX. I don't know
> if it is customary to strip GIT out of Apache tarballs, but still we
> need to accept users that have no GIT skills.
>
> It is one of the core principles of NuttX that "all users matter" and
> that we do nothing to restrict the use of the OS, especially not to
> make out internal life simpler at the expense of a world of users. We
> should do the opposite; we should keep the complexit o y inside the
> project and do all we can to make NuttX accessible to all users.
>
> Greg
>
Re: Contributions (PR or patches)
Posted by David Sidrane <da...@apache.org>.
I would like to reboot this. I would question some of these statements that are conditioned by history: Greg repeatedly stated that he hated PR and prefers patches. So to work with NuttX people sent patches. This is a fresh start, and the value of it is to be able to ASK the group what their preferred workflow would be and WHY. Then discuss the merits, educate each other on the value of approaches and then make an informed decisions.
Davdi
On 2019/12/16 01:45:54, Gregory Nutt <sp...@gmail.com> wrote:
>
> > I am just wondering if we are excluding any users by forcing everyone
> > to use PRs. I personally don't have problems with mixed PRs and
> > patches, provided that the patches apply clean. I think we should
> > take the side of the lowest common denominator user and NOT the point
> > of view that makes our job the slickest.
> >
> Remember that the majority of NuttX users do not use git at all. They
> use the release tarballs which have all GIT information stripped out.
> No GIT and not GIT knowledge is required to use NuttX. I don't know if
> it is customary to strip GIT out of Apache tarballs, but still we need
> to accept users that have no GIT skills.
>
> It is one of the core principles of NuttX that "all users matter" and
> that we do nothing to restrict the use of the OS, especially not to make
> out internal life simpler at the expense of a world of users. We should
> do the opposite; we should keep the complexit o y inside the project and
> do all we can to make NuttX accessible to all users.
>
> Greg
>
>
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
> I am just wondering if we are excluding any users by forcing everyone
> to use PRs. I personally don't have problems with mixed PRs and
> patches, provided that the patches apply clean. I think we should
> take the side of the lowest common denominator user and NOT the point
> of view that makes our job the slickest.
>
Remember that the majority of NuttX users do not use git at all. They
use the release tarballs which have all GIT information stripped out.
No GIT and not GIT knowledge is required to use NuttX. I don't know if
it is customary to strip GIT out of Apache tarballs, but still we need
to accept users that have no GIT skills.
It is one of the core principles of NuttX that "all users matter" and
that we do nothing to restrict the use of the OS, especially not to make
out internal life simpler at the expense of a world of users. We should
do the opposite; we should keep the complexit o y inside the project and
do all we can to make NuttX accessible to all users.
Greg
Re: Contributions (PR or patches)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I am just wondering if we are excluding any users by forcing everyone to use PRs.
In my experience there are people why will refuse to use GitHub (because of reasons), they may however still use git.
Thanks,
Justin
Re: Contributions (PR or patches)
Posted by Gregory Nutt <sp...@gmail.com>.
I am just wondering if we are excluding any users by forcing everyone to
use PRs. I personally don't have problems with mixed PRs and patches,
provided that the patches apply clean. I think we should take the side
of the lowest common denominator user and NOT the point of view that
makes our job the slickest.
Greg
On 12/15/2019 7:31 PM, Anthony Merlino wrote:
> As Nathan and others have pointed out, we need to discuss, agree, and
> document how we would like to accept contributions.
>
> I think at most, we should accept patches on the mailing list, and PRs on
> GitHub. But personally, I think we should only support PRs. I think a
> unified method for all contributions is desirable and makes the PPMC's
> lives easier. PRs require less work from committers, and tie into the
> automated build tools easier. They are way easier to keep track of too -
> Github just lists them all for us. They also can be reviewed and merged
> without leaving the browser, assuming the change is valid and the build
> testing has coverage.
>
> What do you think?
>
> Best,
> Anthony
>