www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Wed, 21 Dec 2011 01:31:10 GMT
I have a couple of tangential points to this, had to guess what the right place to insert them
into the discussion was...

On 21/12/2011, at 7:04 AM, Paul Davis wrote:

> The reflog is useful, but I don't think is the end of the story. For
> instance, what happens if an ASF committer works on a branch, and then
> a second ASF committer pushes those changes to master? The reflog
> would tell us that the first ASF committer introduced the code into
> the repository, but the second ASF committer is the person responsible
> for that code eventually going into a release which is (from what I
> understand) the more important of the two roles.
> 
> At this point who gets blamed if something is wrong?

The PMC are responsible for what goes into a release, not an individual. They establish social
norms and use tools to make it easier to track the IP. I imagine who pushed a particular change
to a particular branch is useful information to make available to the developers, but it seems
separate to this discussion.

> 
> Where as, if we instead check that the Git commiter (%ce) field is
> person who should be cleared by a CLA then we don't have such
> questions. And we also don't have to concern ourselves for when the
> initial branch was developed outside of the canonical ASF repository
> (ie, not in the reflog).

An observation I wanted to make from this thread: we seem to talk a lot about a group of people
who have a CLA on file but are not committers (ASF sense of the word). It is great if we can
make signing CLAs easy and making contributions with one easy. However, I believe that group
of people should be small at any point in time - regular contributions should mean that person
is on the path to becoming a committer.

> 
>> * So, instead of checking the %ce field, my proposal would be a check
>> that verifies that either the recorded author or at least one of the
>> (possible multiple) signers-off of an incoming git commit has a CLA on
>> file. And for this to only require rewriting of commits ("git commit
>> --amend -s") when actually needed, the check should be against all the
>> recorded CLAs (ideally with possibly multiple email addresses per CLA)
>> instead of just the committers of a project. Thus an Apache committer
>> would only need to modify an incoming commit if its author doesn't
>> already have a CLA on file.
>> 
> 
> Minus the disagreement on the field we check, this is the goal I'm
> going for. Anyone with a CLA on file can contribute without requiring
> that the patch goes through JIRA. I'm open to revising which fields
> are checked, but it still seems most obvious that the committer (%ce
> field) is the person directly responsible for having cleared the code
> and hence is what should be checked.


I was also having trouble splitting the difference between the approaches. Signing off commits
doesn't seem any easier than re-committing commits. It avoids altering the committer field,
but the more this goes on it seems that field isn't useful information. On the other hand,
checking it does provide a useful utility to projects and simplifies the description of roles
in the project. 

Paul's approach still sounds reasonable to me, at least as the starting point.

What I would find helpful is to list out the important scenarios, and how they'd play out
with the different approaches, along with pros and cons. Is that something that is available
from the CouchDB documentation?

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






Mime
View raw message