You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2014/04/25 20:55:41 UTC
[DISCUSS] Automate signed icla to git commits
The automation of icla contributors being compared to commits was mentioned
in another thread[1].
>> 3 - Code is made up of commits by individuals that have signed the
>> ICLA (or that are trivial commits)
I foresee issues as there are lots of cases where github usernames are not
easily compared to actual names. purplecabbage -> Jesse MacFadyen for one!
In some cases github does not even contain the real name of the user.
Maintaining a list would not only make this easy to automate, but it would
help anyone looking to accept a pull-req from having to vet the
contributor.
This would require a change to our contributor workflow, but how should we
do it? Some ideas.
1. Email to the dev list with a special subject ex. IAM Name->githubUser
2. add your info to a wiki page
3. add git username to the icla form ( not sure we can add to it )
4. when one of us vets someone, we add them to a private? list somewhere
5. ... ?
[1] http://markmail.org/message/qyrvfae7ic526dgw
@purplecabbage
risingj.com
Re: [DISCUSS] Automate signed icla to git commits
Posted by James Jong <wj...@gmail.com>.
Agreed that it is working as intended. It’s also good to know that although Cordova’s been requiring CLA’s for it’s contributions, it isn’t a hard Apache requirement. For some contributions I’ve wanted to pull in, the CLA has been the holdup. Thanks for the clarification.
-James Jong
On Apr 28, 2014, at 10:40 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I'm pretty confident it's working as intended for now.
>
>
> On Mon, Apr 28, 2014 at 3:05 PM, Marvin Humphrey <ma...@rectangular.com>wrote:
>
>> On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>> Interesting! Going by this description, it sounds like we wound't need
>>> ICLAs for the majority of pull requests since pull requests details get
>>> forwarded to the mailing-list.
>>
>> Legally, the party making the pull request implicitly asserts that they
>> have
>> the right to contribute the commits under the ALv2 section 5.
>>
>> However, if a release with infringing material escapes out into the wild,
>> having somebody to blame will be cold comfort. Should the original
>> copyright
>> owner request that we cease distributing the offending release, Cordova's
>> users are going to be in a bad situation regardless.
>>
>>> New proposal: don't worry about CLAs at release time.
>>
>> The key here is that the Cordova PMC needs to be vigilant with every pull
>> request from somebody who has not signed a CLA or is otherwise well-known
>> to
>> be submitting clean IP. The Cordova committer who accepts the pull request
>> and pushes to the ASF repo is the first line of defense. However, the
>> rest of
>> the PMC is also collectively responsible for reviewing all commits.
>>
>> So the question is, how confident are you in the existing review process?
>> If
>> it's working as intended, then there's indeed no need to perform an
>> additional
>> audit at release time. On the other hand if it's porous, then building in
>> more checks might be wise.
>>
>> Marvin Humphrey
>>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Andrew Grieve <ag...@chromium.org>.
I'm pretty confident it's working as intended for now.
On Mon, Apr 28, 2014 at 3:05 PM, Marvin Humphrey <ma...@rectangular.com>wrote:
> On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Interesting! Going by this description, it sounds like we wound't need
> > ICLAs for the majority of pull requests since pull requests details get
> > forwarded to the mailing-list.
>
> Legally, the party making the pull request implicitly asserts that they
> have
> the right to contribute the commits under the ALv2 section 5.
>
> However, if a release with infringing material escapes out into the wild,
> having somebody to blame will be cold comfort. Should the original
> copyright
> owner request that we cease distributing the offending release, Cordova's
> users are going to be in a bad situation regardless.
>
> > New proposal: don't worry about CLAs at release time.
>
> The key here is that the Cordova PMC needs to be vigilant with every pull
> request from somebody who has not signed a CLA or is otherwise well-known
> to
> be submitting clean IP. The Cordova committer who accepts the pull request
> and pushes to the ASF repo is the first line of defense. However, the
> rest of
> the PMC is also collectively responsible for reviewing all commits.
>
> So the question is, how confident are you in the existing review process?
> If
> it's working as intended, then there's indeed no need to perform an
> additional
> audit at release time. On the other hand if it's porous, then building in
> more checks might be wise.
>
> Marvin Humphrey
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Interesting! Going by this description, it sounds like we wound't need
> ICLAs for the majority of pull requests since pull requests details get
> forwarded to the mailing-list.
Legally, the party making the pull request implicitly asserts that they have
the right to contribute the commits under the ALv2 section 5.
However, if a release with infringing material escapes out into the wild,
having somebody to blame will be cold comfort. Should the original copyright
owner request that we cease distributing the offending release, Cordova's
users are going to be in a bad situation regardless.
> New proposal: don't worry about CLAs at release time.
The key here is that the Cordova PMC needs to be vigilant with every pull
request from somebody who has not signed a CLA or is otherwise well-known to
be submitting clean IP. The Cordova committer who accepts the pull request
and pushes to the ASF repo is the first line of defense. However, the rest of
the PMC is also collectively responsible for reviewing all commits.
So the question is, how confident are you in the existing review process? If
it's working as intended, then there's indeed no need to perform an additional
audit at release time. On the other hand if it's porous, then building in
more checks might be wise.
Marvin Humphrey
Re: [DISCUSS] Automate signed icla to git commits
Posted by Andrew Grieve <ag...@chromium.org>.
Interesting! Going by this description, it sounds like we wound't need
ICLAs for the majority of pull requests since pull requests details get
forwarded to the mailing-list.
New proposal: don't worry about CLAs at release time.
On Fri, Apr 25, 2014 at 5:43 PM, Marvin Humphrey <ma...@rectangular.com>wrote:
> On Fri, Apr 25, 2014 at 12:42 PM, Jesse <pu...@gmail.com> wrote:
> > We can accept trivial commits without an ICLA, so the commit hook would
> > need a firm definition of 'trivial'.
>
> Section 5 of the ALv2 covers contributions:
>
> http://www.apache.org/licenses/LICENSE-2.0.html#contributions
>
> 5. Submission of Contributions.
>
> 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. [...]
>
> Technically, Apache doesn't require an ICLA or software grant for
> submissions, no
> matter what the size. What we need is documentation of the contributor's
> intent to contribute, captured within Apache-archived communication
> channels
> (mailing list, bug tracker, etc.). If we have that, then the ALv2 section
> 5
> covers us legally.
>
> The ASF requires an ICLA for all *committers* to cover submissions which
> are
> committed directly into an Apache repo, but that's different.
>
> Nevertheless, it's considered best practice to obtain additional
> documentation
> from the contributor for large contributions, where "large" is not
> precisely
> defined. That documentation typically takes the form of a CLA or a
> software
> grant.
>
> So by establishing a hard requirement for an ICLA for *all* non-trivial
> contributions, Cordova would actually be going further than is required by
> Apache. That might be a sound policy considering how active Cordova is,
> and
> it's SOP at other places like the Eclipse Foundation. What we definitely
> would like to avoid is integrating important contributions from somebody
> clueless submitting stuff they don't own or somebody whose identity is not
> known. Requiring an ICLA up front would guard against that, at the cost of
> raising the barrier to entry.
>
> HTH,
>
> Marvin Humphrey
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Apr 25, 2014 at 12:42 PM, Jesse <pu...@gmail.com> wrote:
> We can accept trivial commits without an ICLA, so the commit hook would
> need a firm definition of 'trivial'.
Section 5 of the ALv2 covers contributions:
http://www.apache.org/licenses/LICENSE-2.0.html#contributions
5. Submission of Contributions.
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. [...]
Technically, Apache doesn't require an ICLA or software grant for
submissions, no
matter what the size. What we need is documentation of the contributor's
intent to contribute, captured within Apache-archived communication channels
(mailing list, bug tracker, etc.). If we have that, then the ALv2 section 5
covers us legally.
The ASF requires an ICLA for all *committers* to cover submissions which are
committed directly into an Apache repo, but that's different.
Nevertheless, it's considered best practice to obtain additional documentation
from the contributor for large contributions, where "large" is not precisely
defined. That documentation typically takes the form of a CLA or a software
grant.
So by establishing a hard requirement for an ICLA for *all* non-trivial
contributions, Cordova would actually be going further than is required by
Apache. That might be a sound policy considering how active Cordova is, and
it's SOP at other places like the Eclipse Foundation. What we definitely
would like to avoid is integrating important contributions from somebody
clueless submitting stuff they don't own or somebody whose identity is not
known. Requiring an ICLA up front would guard against that, at the cost of
raising the barrier to entry.
HTH,
Marvin Humphrey
Re: [DISCUSS] Automate signed icla to git commits
Posted by Michal Mocny <mm...@chromium.org>.
Thats a decent plan.
(But instead of LOC for threshold I'd do weighted hamming distance that
puts little weight on whitespace and semicolons etc. ;)
-Michal
On Fri, Apr 25, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com> wrote:
> Andrew Grieve wrote:
> > How about: trivial = < 10 lines || commit hash exists in a
> > trivial-commits.txt file?
>
> trivial-commits should be in a different repo (coho?)
>
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Josh Soref <js...@blackberry.com>.
Jesse wrote:
> again: I would rather leave the definition of 'trivial' to the reviewer
>of
> the pull request.
>
> An update to docs of 100 lines can be trivial ... Josh renaming 'cordova'
> to 'Cordova' across 3 repos, and 15 files, could be considered trivial
>...
> 4 lines of critical code could be non-trivial.
>
> Note, I am not calling out Josh, I am just making a more specific
>example,
> valuable and trivial are different things.
Nothing wrong with using me as an example of such things. I tend to cover
most interesting edge cases, so it's a good idea to check to see if any of
my actions are relevant edges that should be addressed.
Re: [DISCUSS] Automate signed icla to git commits
Posted by Jesse <pu...@gmail.com>.
again: I would rather leave the definition of 'trivial' to the reviewer of
the pull request.
An update to docs of 100 lines can be trivial ... Josh renaming 'cordova'
to 'Cordova' across 3 repos, and 15 files, could be considered trivial ...
4 lines of critical code could be non-trivial.
Note, I am not calling out Josh, I am just making a more specific example,
valuable and trivial are different things.
@purplecabbage
risingj.com
On Fri, Apr 25, 2014 at 1:00 PM, Josh Soref <js...@blackberry.com> wrote:
> Andrew Grieve wrote:
> > How about: trivial = < 10 lines || commit hash exists in a
> > trivial-commits.txt file?
>
> trivial-commits should be in a different repo (coho?)
>
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by James Jong <wj...@gmail.com>.
+1
-James Jong
On Apr 25, 2014, at 4:10 PM, Ian Clelland <ic...@chromium.org> wrote:
> Instead, just don't worry about any commit hook, and have a coho tool that
> scans the repo for all commits *since the last release* -- not since the
> beginning of time -- looking for non-CLA-signed-contributions. The release
> manager can make an executive decision at that point.
Re: [DISCUSS] Automate signed icla to git commits
Posted by Ian Clelland <ic...@chromium.org>.
I doubt we could do a <10 lines policy -- I'm sure there are plenty of
significant changes that could be implemented in 10 lines or less. (Or a
series of <10 line commits)
I wouldn't want to have any policy in place that made it easy for us to
automatically miss potential ASF policy violations.
Instead, just don't worry about any commit hook, and have a coho tool that
scans the repo for all commits *since the last release* -- not since the
beginning of time -- looking for non-CLA-signed-contributions. The release
manager can make an executive decision at that point.
This way, the release process becomes a gate, of sorts. We always know that
someone has vetted all of the contributions up to and including the last
signed release, and only have to worry about the small number of commits
that have happened since.
On Fri, Apr 25, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com> wrote:
> Andrew Grieve wrote:
> > How about: trivial = < 10 lines || commit hash exists in a
> > trivial-commits.txt file?
>
> trivial-commits should be in a different repo (coho?)
>
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Josh Soref <js...@blackberry.com>.
Andrew Grieve wrote:
> How about: trivial = < 10 lines || commit hash exists in a
> trivial-commits.txt file?
trivial-commits should be in a different repo (coho?)
Re: [DISCUSS] Automate signed icla to git commits
Posted by Andrew Grieve <ag...@chromium.org>.
How about: trivial = < 10 lines || commit hash exists in a
trivial-commits.txt file?
On Fri, Apr 25, 2014 at 3:42 PM, Jesse <pu...@gmail.com> wrote:
> We can accept trivial commits without an ICLA, so the commit hook would
> need a firm definition of 'trivial'.
> Sounds like more work than it is worth, I would rather leave the definition
> of 'trivial' to the reviewer of the pull request.
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Apr 25, 2014 at 12:37 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
>
> > This sounds to me like the simplest approach.
> >
> > Would a git commit hook catch this scenario so a commit never goes in
> > without ICLA verification? Even if a non-ICLA author's commit can be
> > reverted, that content is still in the repo, which doesn't sound idea.
> >
> > On Apr 25, 2014, at 3:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > > Instead of having a map of username -> Real Name, we could maintain a
> > list
> > > of usernames that we know have a valid ICLA.
> >
> >
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Jesse <pu...@gmail.com>.
We can accept trivial commits without an ICLA, so the commit hook would
need a firm definition of 'trivial'.
Sounds like more work than it is worth, I would rather leave the definition
of 'trivial' to the reviewer of the pull request.
@purplecabbage
risingj.com
On Fri, Apr 25, 2014 at 12:37 PM, Marcel Kinard <cm...@gmail.com> wrote:
> This sounds to me like the simplest approach.
>
> Would a git commit hook catch this scenario so a commit never goes in
> without ICLA verification? Even if a non-ICLA author's commit can be
> reverted, that content is still in the repo, which doesn't sound idea.
>
> On Apr 25, 2014, at 3:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> > Instead of having a map of username -> Real Name, we could maintain a
> list
> > of usernames that we know have a valid ICLA.
>
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Andrew Grieve <ag...@chromium.org>.
As long as we don't release with their code in it, I think it's fine for it
to be committed & then reverted.
Note too, that AFAIK, there's no way for us to verify CCLAs :S
I was imagining adding this to our automated build. E.g. maybe have a coho
command for doing this, and then having our build fail if that command ever
fails.
On Fri, Apr 25, 2014 at 3:37 PM, Marcel Kinard <cm...@gmail.com> wrote:
> This sounds to me like the simplest approach.
>
> Would a git commit hook catch this scenario so a commit never goes in
> without ICLA verification? Even if a non-ICLA author's commit can be
> reverted, that content is still in the repo, which doesn't sound idea.
>
> On Apr 25, 2014, at 3:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> > Instead of having a map of username -> Real Name, we could maintain a
> list
> > of usernames that we know have a valid ICLA.
>
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Marcel Kinard <cm...@gmail.com>.
This sounds to me like the simplest approach.
Would a git commit hook catch this scenario so a commit never goes in without ICLA verification? Even if a non-ICLA author's commit can be reverted, that content is still in the repo, which doesn't sound idea.
On Apr 25, 2014, at 3:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Instead of having a map of username -> Real Name, we could maintain a list
> of usernames that we know have a valid ICLA.
Re: [DISCUSS] Automate signed icla to git commits
Posted by Andrew Grieve <ag...@chromium.org>.
Instead of having a map of username -> Real Name, we could maintain a list
of usernames that we know have a valid ICLA.
AUTHORs files might if we want to maintain them in every repo that we have.
On Fri, Apr 25, 2014 at 3:16 PM, Michal Mocny <mm...@chromium.org> wrote:
> Yeah first thing that come to my mind was to just add it as part of the
> commit itself, so AUTHORS and/or COMMITTERS files.
>
> This means that we don't append anything with coho, we just do, git patch
> author -> lookup in AUTHORS -> get real name -> lookup in apache list
>
> We could even make a git commit (or maybe push?) hook to verify that AUTHOR
> is filled in properly, and warn about ICLA at that point?
>
> -Michal
>
>
> On Fri, Apr 25, 2014 at 3:03 PM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > How about an AUTHORS file in (one|each) of the repos? They're usually
> > supposed to be human-readable, but it wouldn't take much to make it
> > machine-readable as well, and have coho output a list of new authors to
> vet
> > and append to it on each release.
> >
> >
> > On Fri, Apr 25, 2014 at 2:55 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > The automation of icla contributors being compared to commits was
> > mentioned
> > > in another thread[1].
> > >
> > > >> 3 - Code is made up of commits by individuals that have signed the
> > > >> ICLA (or that are trivial commits)
> > >
> > > I foresee issues as there are lots of cases where github usernames are
> > not
> > > easily compared to actual names. purplecabbage -> Jesse MacFadyen for
> > one!
> > > In some cases github does not even contain the real name of the user.
> > >
> > > Maintaining a list would not only make this easy to automate, but it
> > would
> > > help anyone looking to accept a pull-req from having to vet the
> > > contributor.
> > >
> > > This would require a change to our contributor workflow, but how should
> > we
> > > do it? Some ideas.
> > > 1. Email to the dev list with a special subject ex. IAM
> Name->githubUser
> > > 2. add your info to a wiki page
> > > 3. add git username to the icla form ( not sure we can add to it )
> > > 4. when one of us vets someone, we add them to a private? list
> somewhere
> > > 5. ... ?
> > >
> > >
> > >
> > > [1] http://markmail.org/message/qyrvfae7ic526dgw
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> >
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Michal Mocny <mm...@chromium.org>.
Yeah first thing that come to my mind was to just add it as part of the
commit itself, so AUTHORS and/or COMMITTERS files.
This means that we don't append anything with coho, we just do, git patch
author -> lookup in AUTHORS -> get real name -> lookup in apache list
We could even make a git commit (or maybe push?) hook to verify that AUTHOR
is filled in properly, and warn about ICLA at that point?
-Michal
On Fri, Apr 25, 2014 at 3:03 PM, Ian Clelland <ic...@chromium.org>wrote:
> How about an AUTHORS file in (one|each) of the repos? They're usually
> supposed to be human-readable, but it wouldn't take much to make it
> machine-readable as well, and have coho output a list of new authors to vet
> and append to it on each release.
>
>
> On Fri, Apr 25, 2014 at 2:55 PM, Jesse <pu...@gmail.com> wrote:
>
> > The automation of icla contributors being compared to commits was
> mentioned
> > in another thread[1].
> >
> > >> 3 - Code is made up of commits by individuals that have signed the
> > >> ICLA (or that are trivial commits)
> >
> > I foresee issues as there are lots of cases where github usernames are
> not
> > easily compared to actual names. purplecabbage -> Jesse MacFadyen for
> one!
> > In some cases github does not even contain the real name of the user.
> >
> > Maintaining a list would not only make this easy to automate, but it
> would
> > help anyone looking to accept a pull-req from having to vet the
> > contributor.
> >
> > This would require a change to our contributor workflow, but how should
> we
> > do it? Some ideas.
> > 1. Email to the dev list with a special subject ex. IAM Name->githubUser
> > 2. add your info to a wiki page
> > 3. add git username to the icla form ( not sure we can add to it )
> > 4. when one of us vets someone, we add them to a private? list somewhere
> > 5. ... ?
> >
> >
> >
> > [1] http://markmail.org/message/qyrvfae7ic526dgw
> >
> > @purplecabbage
> > risingj.com
> >
>
Re: [DISCUSS] Automate signed icla to git commits
Posted by Ian Clelland <ic...@chromium.org>.
How about an AUTHORS file in (one|each) of the repos? They're usually
supposed to be human-readable, but it wouldn't take much to make it
machine-readable as well, and have coho output a list of new authors to vet
and append to it on each release.
On Fri, Apr 25, 2014 at 2:55 PM, Jesse <pu...@gmail.com> wrote:
> The automation of icla contributors being compared to commits was mentioned
> in another thread[1].
>
> >> 3 - Code is made up of commits by individuals that have signed the
> >> ICLA (or that are trivial commits)
>
> I foresee issues as there are lots of cases where github usernames are not
> easily compared to actual names. purplecabbage -> Jesse MacFadyen for one!
> In some cases github does not even contain the real name of the user.
>
> Maintaining a list would not only make this easy to automate, but it would
> help anyone looking to accept a pull-req from having to vet the
> contributor.
>
> This would require a change to our contributor workflow, but how should we
> do it? Some ideas.
> 1. Email to the dev list with a special subject ex. IAM Name->githubUser
> 2. add your info to a wiki page
> 3. add git username to the icla form ( not sure we can add to it )
> 4. when one of us vets someone, we add them to a private? list somewhere
> 5. ... ?
>
>
>
> [1] http://markmail.org/message/qyrvfae7ic526dgw
>
> @purplecabbage
> risingj.com
>