www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Mon, 19 Dec 2011 03:30:53 GMT
On Sun, Dec 18, 2011 at 1:40 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Dec 15, 2011, at 8:05 AM, Paul Davis wrote:
>> On Thu, Dec 15, 2011 at 5:39 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>>> Hi,
>>> On Thu, Dec 15, 2011 at 1:53 AM, Paul Davis <paul.joseph.davis@gmail.com>
>>>> On the other hand, I do worry about people that aren't completely
>>>> familiar with Git will end up shooting themselves in the foot. And
>>>> while we do have policies in place to handle such mess ups, why not
>>>> spend a bit of time developing a system that automatically prevents a
>>>> large class of accidents?
>>> The problem here is that such an automatic prevention system is
>>> interfering with valid workflows (i.e. pull requests) of projects like
>>> Cordova/Callback that are already familiar with Git.
>> The issue here is that I'm uncomfortable *not* interfering with these
>> workflows. Especially for new projects that  might not have
>> internalized the various requirements for pushing code. Especially for
>> projects that have spent a good deal of time operating in mode that is
>> quite specifically not at the same rigorous standards of what it takes
>> to push code into an Apache project. There absolutely should be a step
>> where committers are forced to think, "Is this code acceptable for
>> inclusion?"
>> I'm more than willing to change this step so that we use ldap or even
>> just a text file listing the email address of anyone that is covered
>> by an ICLA or CCLA. But just removing it and hoping that new
>> committers grok what it means to vet provenance and maintain the legal
>> standing of their code base doesn't strike me as a workable solution.
>> This way new projects have zero questions on what can be included when
>> they go to commit.
> Umm, except that check is wrong.  We don't require an iCLA from everyone
> who contributes to an Apache project.  We only require iCLAs for people
> who submit major changes (like whole new feature sets) or if they want
> an account on apache.org (pusher).  The folks who push the code changes
> to Apache are responsible for ensuring that we have the rights when
> they push third-party code.
> I agree with Jukka -- the infrastructure for git should not add
> restrictions that we have never needed for svn.
> ....Roy

This doesn't require every commit to be authored by someone with an
ICLA, it merely requires all commits are committed by someone with an
ICLA. And the general hope is that this would be extended to be anyone
that has an ICLA as opposed to a committer on the current project
which is less restrictive than SVN.

Its also important to note that we're not the only ones with this
check. The Eclipse project has the same requirement [1].

To say that we're adding a restriction to Git that SVN never needed is
like saying that cars don't need steering wheels because trains never
needed one. The distinction between author, committer, and pusher is
an entirely new concept in Git that doesn't exist in SVN.

Alternatively, the current standard operating procedure is for non
trivial patches to pass through JIRA to indicate the contribution is
covered by the ASL 2.0. If we assume that this requirement is still in
place then the entire check is reduced to a relatively mundane
assurance that clients are configured properly.

I'm not against looking for alternatives to this check or even
deleting it entirely, but it worries me a bit that the justification
for change is allowing GitHub Pull Requests or that its not something
we had to consider for SVN.

[1] http://wiki.eclipse.org/Git#IP_process_implications_of_DVCS

View raw message