Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

This is in relation with "Github PRs and Jira" thread (https://markmail.org/message/s422zuivbmzglph4)

Below is my 1st experience of GitHub PR merge in the context of ASF dual hosting with GitBox. So I somehow made a jump in the void...

After reviewing the change I picked "squash and merge PR" among the 3 GitHub PR merge options. Because I did not want to break the linear Git flow, it
seemed the best option. But despite "squashing" we got  3 commits; 2 from Daniel Watford and one from I. I don't know if it's possible to do otherwise
with the 2 other options. Maybe it's good to know that Daniel contributed...

Also I expected that my comment in GitHub would be used as the final commit comment. So I then tried to amend the commit by modifying ONLY the
comment, and then push comment after a pull. But I got a fast-forward issue and after trying several pull and push tricks I understood I'll never pass
over this issue:

    "[remote rejected]       trunk -> trunk (pre-receive hook declined)"

Because it's related to having "receive.denynonfastforwards" set to true on GitBox server[1] and I don't want to annoy Infra to temporary set it true
for a such change.

But I really wanted to change the commit comment to follow our template. So I decided to pull rebase, slightly change the ComponentContainerTest
class, commit and push. Hence I created a new commit, somehow a duplicate of the PR merge, at least with a correctly formatted comment.

This was an awkward experience, I don't know if i could have done it better, ideas, advices?
Maybe advising contributors to use our template in commit comments used by GitHub PRs?
Also we can ask our contributors to use in the PRs title the format of our commit template. For instance in[2] instead of

    OFBIZ-11331: Allow ComponentContainerTest to run on windows
    rather
    Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)

    Then the commit/s would contain the explanations.

I just fear we will have sometimes to explain, and ask contributors to edit their comments or titles...

I'll sleep on it and wait for comments before doing any additions or changes in our documentation about that, in relation with the "Github PRs and
Jira" thread

Thanks

Jacques
[1] https://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repository
[2] https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=commit;h=6d194cf8c363435e212282e31f575ca93f14d72d


Le 28/01/2020 à 15:58, [hidden email] a écrit :

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a change to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git.
>
>
>      from 6f39741  Fixed: Fixed the issue on party page that will upload the data each time after refreshing the page. (OFBIZ-11325)
>       add 0c2124a  Get Path from URI than a string representation of a file path when building Path to test resources.
>       add 259f71d  Removed unused test imports.
>       new 6d194cf  OFBIZ-11331: Allow ComponentContainerTest to run on windows (#8)
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
>
>
> Summary of changes:
>   .../apache/ofbiz/base/container/ComponentContainerTest.java  | 12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
>

[Mathieu Lirzin]

Hello Jacques,

"[hidden email]" <[hidden email]> writes:

> This is in relation with "Github PRs and Jira" thread (https://markmail.org/message/s422zuivbmzglph4)
>
> Below is my 1st experience of GitHub PR merge in the context of ASF dual hosting with GitBox. So I somehow made a jump in the void...
>
> After reviewing the change I picked "squash and merge PR" among the 3
> GitHub PR merge options. Because I did not want to break the linear
> Git flow, it seemed the best option. But despite "squashing" we got  3
> commits; 2 from Daniel Watford and one from I. I don't know if it's
> possible to do otherwise with the 2 other options. Maybe it's good to
> know that Daniel contributed...
>
> Also I expected that my comment in GitHub would be used as the final
> commit comment. So I then tried to amend the commit by modifying ONLY
> the comment, and then push comment after a pull. But I got a
> fast-forward issue and after trying several pull and push tricks I
> understood I'll never pass over this issue:
>
>    "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
>
> Because it's related to having "receive.denynonfastforwards" set to
> true on GitBox server[1] and I don't want to annoy Infra to temporary
> set it true for a such change.

One must never, never, never rewrite history of the trunk branch. :-)

> But I really wanted to change the commit comment to follow our
> template. So I decided to pull rebase, slightly change the
> ComponentContainerTest class, commit and push. Hence I created a new
> commit, somehow a duplicate of the PR merge, at least with a correctly
> formatted comment.
>
> This was an awkward experience, I don't know if i could have done it better, ideas, advices?
> Maybe advising contributors to use our template in commit comments used by GitHub PRs?

The best option I think is to clone the branch locally, amend the
necessary commits, push on the PR branch ask for validation from the
original author, and then from your terminal rebase on trunk and
fast-forward merge the commits (meaning without a merge commit).

Basically the better option to use Github Web interface only for
discussion/review.

> Also we can ask our contributors to use in the PRs title the format of
> our commit template. For instance in[2] instead of
>
>    OFBIZ-11331: Allow ComponentContainerTest to run on windows
>    rather
>    Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)
>
>    Then the commit/s would contain the explanations.
>
> I just fear we will have sometimes to explain, and ask contributors to edit their comments or titles...
>
> I'll sleep on it and wait for comments before doing any additions or
> changes in our documentation about that, in relation with the "Github
> PRs and Jira" thread

I think it would be better to not use the PR feature as long as there is
not a community consensus that this is an acceptable contribution
channel.  As stated previously I am not against adopting Github PR *if
and only if* we have a plan to move out of Jira.

Given the pile of existing policies, I don't think this is a good idea
to simply provide more contribution options/policies, I think it is
important to review existing ones and consider replacing some of them.

For example we could deprecate patch based contribution, or at least
adopt the ‘git format-patch’ conventions.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Michael Brohl-3]

Hi Mathieu, Jacques,

inline...

Am 28.01.20 um 20:31 schrieb Mathieu Lirzin:
> Hello Jacques,
>
> "[hidden email]" <[hidden email]> writes:
>
>> This is in relation with "Github PRs and Jira" thread (https://markmail.org/message/s422zuivbmzglph4)
>>
>> Below is my 1st experience of GitHub PR merge in the context of ASF dual hosting with GitBox. So I somehow made a jump in the void...
...

>>
>> After reviewing the change I picked "squash and merge PR" among the 3
>> GitHub PR merge options. Because I did not want to break the linear
>> Git flow, it seemed the best option. But despite "squashing" we got  3
>> commits; 2 from Daniel Watford and one from I. I don't know if it's
>> possible to do otherwise with the 2 other options. Maybe it's good to
>> know that Daniel contributed...
>>
>> Also I expected that my comment in GitHub would be used as the final
>> commit comment. So I then tried to amend the commit by modifying ONLY
>> the comment, and then push comment after a pull. But I got a
>> fast-forward issue and after trying several pull and push tricks I
>> understood I'll never pass over this issue:
>>
>>     "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
>>
>> Because it's related to having "receive.denynonfastforwards" set to
>> true on GitBox server[1] and I don't want to annoy Infra to temporary
>> set it true for a such change.
> One must never, never, never rewrite history of the trunk branch. :-)

+1 !

I like to add that I appreciate experiments and learning, especially if
the experience is shared like Jacques did.

It should not affect the official repositories though.

...

>> Also we can ask our contributors to use in the PRs title the format of
>> our commit template. For instance in[2] instead of
>>
>>     OFBIZ-11331: Allow ComponentContainerTest to run on windows
>>     rather
>>     Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)
>>
>>     Then the commit/s would contain the explanations.
>>
>> I just fear we will have sometimes to explain, and ask contributors to edit their comments or titles...
>>
>> I'll sleep on it and wait for comments before doing any additions or
>> changes in our documentation about that, in relation with the "Github
>> PRs and Jira" thread
> I think it would be better to not use the PR feature as long as there is
> not a community consensus that this is an acceptable contribution
> channel.  As stated previously I am not against adopting Github PR *if
> and only if* we have a plan to move out of Jira.
>
> Given the pile of existing policies, I don't think this is a good idea
> to simply provide more contribution options/policies, I think it is
> important to review existing ones and consider replacing some of them.

+1 for these statements.
>
> For example we could deprecate patch based contribution, or at least
> adopt the ‘git format-patch’ conventions.

Not sure if we necessarily have to deprecate the patch based
contributions. It could be a simpler way for contributors to provide a
change, especially if they are not developers and/or familiar with the
pull request mechanisms. Maybe the patch based way becomes obsolete
naturally but I would not force it.

We should work out a simple, documented way how to do it with PR's and
encourage contributors to use it, including using proper commit
statements following our template to prevent doing correctional work on
the committers site.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

[Michael Brohl-3]

Hi Jacques,

inline...

Am 28.01.20 um 19:05 schrieb [hidden email]:

> This is in relation with "Github PRs and Jira" thread
> (https://markmail.org/message/s422zuivbmzglph4)
>
> Below is my 1st experience of GitHub PR merge in the context of ASF
> dual hosting with GitBox. So I somehow made a jump in the void...
>
> After reviewing the change I picked "squash and merge PR" among the 3
> GitHub PR merge options. Because I did not want to break the linear
> Git flow, it seemed the best option. But despite "squashing" we got  3
> commits; 2 from Daniel Watford and one from I. I don't know if it's
> possible to do otherwise with the 2 other options. Maybe it's good to
> know that Daniel contributed...
>
> Also I expected that my comment in GitHub would be used as the final
> commit comment. So I then tried to amend the commit by modifying ONLY
> the comment, and then push comment after a pull. But I got a
> fast-forward issue and after trying several pull and push tricks I
> understood I'll never pass over this issue:
>
>    "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
>
> Because it's related to having "receive.denynonfastforwards" set to
> true on GitBox server[1] and I don't want to annoy Infra to temporary
> set it true for a such change.
>
> But I really wanted to change the commit comment to follow our
> template. So I decided to pull rebase, slightly change the
> ComponentContainerTest class, commit and push. Hence I created a new
> commit, somehow a duplicate of the PR merge, at least with a correctly
> formatted comment.
>
> This was an awkward experience, I don't know if i could have done it
> better, ideas, advices?
> Maybe advising contributors to use our template in commit comments
> used by GitHub PRs?
> Also we can ask our contributors to use in the PRs title the format of
> our commit template. For instance in[2] instead of

I would go so far to make the proper use of the templates a restriction
to get the PR into the codebase. We should make the committer's work as
easy as possible.

...


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

[Pierre Smits-3]

I agree with Micheal here that the project should not impose restrictions
on how non-privileged provide their enhancements.

Indeed, those helping non-privileged contributors should be helped to do
their part as easy as possible.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Jan 29, 2020 at 8:02 AM Michael Brohl <[hidden email]>
wrote:

> Hi Jacques,
>
> inline...
>
> Am 28.01.20 um 19:05 schrieb [hidden email]:
> > This is in relation with "Github PRs and Jira" thread
> > (https://markmail.org/message/s422zuivbmzglph4)
> >
> > Below is my 1st experience of GitHub PR merge in the context of ASF
> > dual hosting with GitBox. So I somehow made a jump in the void...
> >
> > After reviewing the change I picked "squash and merge PR" among the 3
> > GitHub PR merge options. Because I did not want to break the linear
> > Git flow, it seemed the best option. But despite "squashing" we got  3
> > commits; 2 from Daniel Watford and one from I. I don't know if it's
> > possible to do otherwise with the 2 other options. Maybe it's good to
> > know that Daniel contributed...
> >
> > Also I expected that my comment in GitHub would be used as the final
> > commit comment. So I then tried to amend the commit by modifying ONLY
> > the comment, and then push comment after a pull. But I got a
> > fast-forward issue and after trying several pull and push tricks I
> > understood I'll never pass over this issue:
> >
> >    "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
> >
> > Because it's related to having "receive.denynonfastforwards" set to
> > true on GitBox server[1] and I don't want to annoy Infra to temporary
> > set it true for a such change.
> >
> > But I really wanted to change the commit comment to follow our
> > template. So I decided to pull rebase, slightly change the
> > ComponentContainerTest class, commit and push. Hence I created a new
> > commit, somehow a duplicate of the PR merge, at least with a correctly
> > formatted comment.
> >
> > This was an awkward experience, I don't know if i could have done it
> > better, ideas, advices?
> > Maybe advising contributors to use our template in commit comments
> > used by GitHub PRs?
> > Also we can ask our contributors to use in the PRs title the format of
> > our commit template. For instance in[2] instead of
>
> I would go so far to make the proper use of the templates a restriction
> to get the PR into the codebase. We should make the committer's work as
> easy as possible.
>
> ...
>
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
>

[Jacques Le Roux]

Hi Mathieu,

Inline...

Le 28/01/2020 à 20:31, Mathieu Lirzin a écrit :

> Hello Jacques,
>
> "[hidden email]" <[hidden email]> writes:
>
>> But I got a
>> fast-forward issue and after trying several pull and push tricks I
>> understood I'll never pass over this issue:
>>
>>     "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
>>
>> Because it's related to having "receive.denynonfastforwards" set to
>> true on GitBox server[1] and I don't want to annoy Infra to temporary
>> set it true for a such change.
> One must never, never, never rewrite history of the trunk branch. :-)

Yes I know and I did not :)


>
>> This was an awkward experience, I don't know if i could have done it better, ideas, advices?
>> Maybe advising contributors to use our template in commit comments used by GitHub PRs?
> The best option I think is to clone the branch locally, amend the
> necessary commits, push on the PR branch ask for validation from the
> original author, and then from your terminal rebase on trunk and
> fast-forward merge the commits (meaning without a merge commit).

Obviously too much work at the expense of committers, at least for me.


> Basically the better option to use Github Web interface only for
> discussion/review.

+1

>
>> Also we can ask our contributors to use in the PRs title the format of
>> our commit template. For instance in[2] instead of
>>
>>     OFBIZ-11331: Allow ComponentContainerTest to run on windows
>>     rather
>>     Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)
>>
>>     Then the commit/s would contain the explanations.
>>
>> I just fear we will have sometimes to explain, and ask contributors to edit their comments or titles...
>>
>> I'll sleep on it and wait for comments before doing any additions or
>> changes in our documentation about that, in relation with the "Github
>> PRs and Jira" thread
> I think it would be better to not use the PR feature as long as there is
> not a community consensus that this is an acceptable contribution
> channel.  As stated previously I am not against adopting Github PR *if
> and only if* we have a plan to move out of Jira.

The problem is that if you use one of the PR merge option you don't get your commit comment following the template. Actually the commit comment is not
yours, it's the contributor's.


> Given the pile of existing policies, I don't think this is a good idea
> to simply provide more contribution options/policies, I think it is
> important to review existing ones and consider replacing some of them.

Yes we have OFBIZ-11301 and OFBIZ-11271 pending for that


> For example we could deprecate patch based contribution, or at least
> adopt the ‘git format-patch’ conventions.

As an Eclipse user I don't really see how it would help me, at least; rather the contrary. I could of course change that and instead of C/P  a patch
safe as a file but it's again more work.

Thanks

Jacques

[Jacques Le Roux]

Le 29/01/2020 à 08:02, Michael Brohl a écrit :

> Hi Jacques,
>
> inline...
>
> Am 28.01.20 um 19:05 schrieb [hidden email]:
>> This was an awkward experience, I don't know if i could have done it better, ideas, advices?
>> Maybe advising contributors to use our template in commit comments used by GitHub PRs?
>> Also we can ask our contributors to use in the PRs title the format of our commit template. For instance in[2] instead of
>
> I would go so far to make the proper use of the templates a restriction to get the PR into the codebase. We should make the committer's work as easy
> as possible.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>

Hi Michael,

For me the current way is the easiest. The burden should not be on the committer. I'll never try again to merge a PR for sure!

Jacques

[Jacques Le Roux]

Hi Pierre,

I don't want to put more burden on the committer size either. From my experience, if we want to continue to use our commit template using PR merge is
not an option.

Jacques

Le 29/01/2020 à 09:05, Pierre Smits a écrit :

> I agree with Micheal here that the project should not impose restrictions
> on how non-privileged provide their enhancements.
>
> Indeed, those helping non-privileged contributors should be helped to do
> their part as easy as possible.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Wed, Jan 29, 2020 at 8:02 AM Michael Brohl <[hidden email]>
> wrote:
>
>> Hi Jacques,
>>
>> inline...
>>
>> Am 28.01.20 um 19:05 schrieb [hidden email]:
>>> This is in relation with "Github PRs and Jira" thread
>>> (https://markmail.org/message/s422zuivbmzglph4)
>>>
>>> Below is my 1st experience of GitHub PR merge in the context of ASF
>>> dual hosting with GitBox. So I somehow made a jump in the void...
>>>
>>> After reviewing the change I picked "squash and merge PR" among the 3
>>> GitHub PR merge options. Because I did not want to break the linear
>>> Git flow, it seemed the best option. But despite "squashing" we got  3
>>> commits; 2 from Daniel Watford and one from I. I don't know if it's
>>> possible to do otherwise with the 2 other options. Maybe it's good to
>>> know that Daniel contributed...
>>>
>>> Also I expected that my comment in GitHub would be used as the final
>>> commit comment. So I then tried to amend the commit by modifying ONLY
>>> the comment, and then push comment after a pull. But I got a
>>> fast-forward issue and after trying several pull and push tricks I
>>> understood I'll never pass over this issue:
>>>
>>>     "[remote rejected]       trunk -> trunk (pre-receive hook declined)"
>>>
>>> Because it's related to having "receive.denynonfastforwards" set to
>>> true on GitBox server[1] and I don't want to annoy Infra to temporary
>>> set it true for a such change.
>>>
>>> But I really wanted to change the commit comment to follow our
>>> template. So I decided to pull rebase, slightly change the
>>> ComponentContainerTest class, commit and push. Hence I created a new
>>> commit, somehow a duplicate of the PR merge, at least with a correctly
>>> formatted comment.
>>>
>>> This was an awkward experience, I don't know if i could have done it
>>> better, ideas, advices?
>>> Maybe advising contributors to use our template in commit comments
>>> used by GitHub PRs?
>>> Also we can ask our contributors to use in the PRs title the format of
>>> our commit template. For instance in[2] instead of
>> I would go so far to make the proper use of the templates a restriction
>> to get the PR into the codebase. We should make the committer's work as
>> easy as possible.
>>
>> ...
>>
>>
>> Thanks,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>>

[Nicolas Malin-2]

Hello

On 29/01/2020 07:58, Michael Brohl wrote:

>
> Not sure if we necessarily have to deprecate the patch based
> contributions. It could be a simpler way for contributors to provide a
> change, especially if they are not developers and/or familiar with the
> pull request mechanisms. Maybe the patch based way becomes obsolete
> naturally but I would not force it.
>
> We should work out a simple, documented way how to do it with PR's and
> encourage contributors to use it, including using proper commit
> statements following our template to prevent doing correctional work
> on the committers site.

I have no strong opinion for path or PR, all seem good for me. But for
PR if the author is the contributer and not the commiter, I have a doubt
about the legal status and the ICLA [1].

  >      The purpose of this agreement is to clearly define the terms
under which intellectual property
  >  has been contributed to the ASF and thereby allow us to defend the
project should there be a
  >  legal dispute regarding the software at some future time. A signed
ICLA is required to be on file
  >  before an individual is given commit rights to any ASF project.

Personally I have a preference to cherry-pick all commits and squash
them and unique commit  with proper commit message

Nicolas

[1] http://www.apache.org/licenses/contributor-agreements.html#clas

[Pierre Smits-3]

According to the ASF there is no legal issue with the status of the
contribution provided by a contributor without an ICLA.

In the license [1] it is stated that:

Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions.


Furthermore, in LEGAL-156 it is stated that PRs of non-privileged
contributors can be accepted, see [2]

Even one of the founders of the ASF has stated (see [3]):

that opinion comes from me speaking as a board member and
author of the Apache License, and has previously been cleared with Apache's
legal team for a long ago discussion with Incubator. We don't need a CLA on
file to accept contributions from non-committers. We just need a clear
intent by the author to contribute under our normal terms.


Though we desire our non-privileged contributors to submit an ICLA, it is
not a requirement (see [4]). When we started the discussion on that subject
the intent was:

   1.  enable non-privileged contributors to express that they were willing
   to do more, and
   2. for the project to be able to recognise those contributors more easy,
   and facilitate the onboarding process



[1] https://www.apache.org/licenses/LICENSE-2.0
[2]
https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
[3]
https://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3CA603FFCE-623B-43E9-87F8-39BAA51C72D1@...%3E
[4]
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors


Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Jan 29, 2020 at 9:44 AM Nicolas Malin <[hidden email]>
wrote:

> Hello
>
> On 29/01/2020 07:58, Michael Brohl wrote:
> >
> > Not sure if we necessarily have to deprecate the patch based
> > contributions. It could be a simpler way for contributors to provide a
> > change, especially if they are not developers and/or familiar with the
> > pull request mechanisms. Maybe the patch based way becomes obsolete
> > naturally but I would not force it.
> >
> > We should work out a simple, documented way how to do it with PR's and
> > encourage contributors to use it, including using proper commit
> > statements following our template to prevent doing correctional work
> > on the committers site.
>
> I have no strong opinion for path or PR, all seem good for me. But for
> PR if the author is the contributer and not the commiter, I have a doubt
> about the legal status and the ICLA [1].
>
>   >      The purpose of this agreement is to clearly define the terms
> under which intellectual property
>   >  has been contributed to the ASF and thereby allow us to defend the
> project should there be a
>   >  legal dispute regarding the software at some future time. A signed
> ICLA is required to be on file
>   >  before an individual is given commit rights to any ASF project.
>
> Personally I have a preference to cherry-pick all commits and squash
> them and unique commit  with proper commit message
>
> Nicolas
>
> [1] http://www.apache.org/licenses/contributor-agreements.html#clas
>
>

[Jacques Le Roux]

Thank you very much Pierre for this clarification,

It remembers me when the checkbox for the same in Jira was removed.

Jacques

Le 29/01/2020 à 10:59, Pierre Smits a écrit :

> According to the ASF there is no legal issue with the status of the
> contribution provided by a contributor without an ICLA.
>
> In the license [1] it is stated that:
>
> Unless You explicitly state otherwise, any Contribution intentionally
> submitted for inclusion in the Work by You to the Licensor shall be under
> the terms and conditions of this License, without any additional terms or
> conditions.
>
>
> Furthermore, in LEGAL-156 it is stated that PRs of non-privileged
> contributors can be accepted, see [2]
>
> Even one of the founders of the ASF has stated (see [3]):
>
> that opinion comes from me speaking as a board member and
> author of the Apache License, and has previously been cleared with Apache's
> legal team for a long ago discussion with Incubator. We don't need a CLA on
> file to accept contributions from non-committers. We just need a clear
> intent by the author to contribute under our normal terms.
>
>
> Though we desire our non-privileged contributors to submit an ICLA, it is
> not a requirement (see [4]). When we started the discussion on that subject
> the intent was:
>
>     1.  enable non-privileged contributors to express that they were willing
>     to do more, and
>     2. for the project to be able to recognise those contributors more easy,
>     and facilitate the onboarding process
>
>
>
> [1] https://www.apache.org/licenses/LICENSE-2.0
> [2]
> https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
> [3]
> https://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3CA603FFCE-623B-43E9-87F8-39BAA51C72D1@...%3E
> [4]
> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors
>
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Wed, Jan 29, 2020 at 9:44 AM Nicolas Malin <[hidden email]>
> wrote:
>
>> Hello
>>
>> On 29/01/2020 07:58, Michael Brohl wrote:
>>> Not sure if we necessarily have to deprecate the patch based
>>> contributions. It could be a simpler way for contributors to provide a
>>> change, especially if they are not developers and/or familiar with the
>>> pull request mechanisms. Maybe the patch based way becomes obsolete
>>> naturally but I would not force it.
>>>
>>> We should work out a simple, documented way how to do it with PR's and
>>> encourage contributors to use it, including using proper commit
>>> statements following our template to prevent doing correctional work
>>> on the committers site.
>> I have no strong opinion for path or PR, all seem good for me. But for
>> PR if the author is the contributer and not the commiter, I have a doubt
>> about the legal status and the ICLA [1].
>>
>>    >      The purpose of this agreement is to clearly define the terms
>> under which intellectual property
>>    >  has been contributed to the ASF and thereby allow us to defend the
>> project should there be a
>>    >  legal dispute regarding the software at some future time. A signed
>> ICLA is required to be on file
>>    >  before an individual is given commit rights to any ASF project.
>>
>> Personally I have a preference to cherry-pick all commits and squash
>> them and unique commit  with proper commit message
>>
>> Nicolas
>>
>> [1] http://www.apache.org/licenses/contributor-agreements.html#clas
>>
>>