www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Mon, 19 Dec 2011 23:15:49 GMT

Perhaps we indeed should try discussing this on a higher level.

I guess we all agree that in the push log we already have a mechanism
that can be used to trace each line of code in a repository back to a
CLA (or a software grant for the initial upload). This was the key
issue that needed to be solved to bring Git up to par with Subversion
in terms of code provenance.

The topic of this debate then turns more around extra rules for
enforcing that even non-committers who contribute a "large enough"
chunk of code should have a CLA on file. The questions then are a)
should we do this, and if yes, b) what's the best way to do it? Here's
my thinking:

a) So far I haven't seen a compelling reason of why we should have
such rules, just vague references on how we can't trust people to do
the right thing. You asked for a discussion on the "resulting issues
of not having these checks". What issues are those? Why don't we have
them already with Subversion? The idea of such checks sounds useful,
but I'm not convinced that we need them in practice. That said, I'm
open to being convinced otherwise. Until that, -0.

b) Assuming there is consensus on having these checks, I think using
%ce is reasonable starting point but not an ideal solution. At the
risk of bikeshedding, here's my alternative proposal:

* I agree with your idea that a good way to approach this would be to
require extra scrutiny on all changes that come from people who don't
have a CLA on file. Asking a committer to explicitly "approve" such
changes (beyond the simple act committing/pushing them) seems like a
reasonable requirement. I also agree that such approval would be best
recorded in a commit message (even when doing so may break Git
history; that's a good incentive on getting the CLA filed).

* I disagree that the %ce field is a good place for such information.
First, using it for this purpose overwrites existing information
recorded for a different purpose. Second, the %ce field always gets
set in a git commit/rebase/cherry-pick/etc. operation, regardless of
whether such "approval" of the contribution is indeed intended. Third,
%ce is a pretty low-level field that few people even know about (it
doesn't show up by default in "git log" and isn't visible on Github).

* IMHO a better place for this information would be a Signed-off-by
line added to the commit message. The Signed-off-by convention was
explicitly created for this purpose [1] and is well supported by many
tools (starting with "git commit -s"). It's also a well-known and
-documented convention whose purpose practically everyone understands
(SCO...). Finally, such Signed-off-by lines are by default visible in
"git log" and on other tools like Github.

* 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.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD#l297


Jukka Zitting

View raw message