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
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 coul
I'm pretty confident it's working as intended for now.
On Mon, Apr 28, 2014 at 3:05 PM, Marvin Humphrey wrote:
> On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve
> wrote:
> > Interesting! Going by this description, it sounds like we wound't need
> > ICLAs for the majority of pull requests since p
On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve 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 t
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 wrote:
> On Fri, A
On Fri, Apr 25, 2014 at 12:42 PM, Jesse 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 Cont
+1
-James Jong
On Apr 25, 2014, at 4:10 PM, Ian Clelland 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
> m
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.
I
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
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 wrote:
> Andrew Grieve wrote:
> > How about: trivial = < 10 lines || commit hash exists in a
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?)
How about: trivial = < 10 lines || commit hash exists in a
trivial-commits.txt file?
On Fri, Apr 25, 2014 at 3:42 PM, Jesse 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 r
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
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,
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 Gri
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 wrote:
> Yeah first thing that come to my mind was t
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 commi
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 wrote:
>
18 matches
Mail list logo
