[A very well-reasoned reply, and I thank you.  Comments in-line.]

On 06/20/2014 08:20 AM, Nico Kadel-Garcia wrote:
> There are a stack of ways to do this, some less reliable than others. 
> They're not clearly making "git clones" of the upstream RHEL git 
> repository. there is some kind of "import" of the files happening. If 
> they're simply unpacking the SRPM's and importing those, cool. 

I too would like a bit more info from Red Hat on this mechanism. They 
don't actually have to provide that info, but it certainly would be nice 
to have.  It would seem easiest to automate either a depackaging of each 
SRPM and import, or a direct importing from the to-be-packaged contents 
of the SRPM prior to writing it out (and signing).  But that is an 
assumption that may or may not be accurate.

> But import/export procedures with git are prone to fascinating 
> discrepancies, some from user error, It creates fascinating risks, and 
> without a carefully comparison toolkit that compares either RHEL 
> SRPM's to git.centos.org's unstated and thus unpredictable layout, or 
> someone with git access to both running "git diff" between the repos, 
> it's a small but very real risk of fascinating discrepancies. I'm 
> afraid that the only way to get a valid, reliable, and *signed* set of 
> source code is going to be to buy subscriptions. 

GPL doesn't require distributed source to be signed, but your final line 
is probably a correct statement.  Although with your fascinating use of 
fascinating in that paragraph, I have to wonder if you've recently 
watched a Star Trek marathon or something..... :-)

And I'm curious as to those cases, specifically some documentation of 
some of the issues involved.  Lots of large projects, including the 
linux kernel, use git, and those artifacts should be (and probably are) 
well documented.  I am not a git guru, by any stretch, but I am curious.

> I'm fairly shocked: it puts all git clones of git.centos.org material 
> at risk of unauthorized modification and pollution of the source code 
> for people trying to build from them. 

This is where the git design should help; no modification can go 
unnoticed, thanks to the manner in which the commit ID's are 
calculated.  The gap is between Red Hat's build process and the import 
of the sources for that process into git.  Once in git, all changes will 
be tracked.

> There's no way, as things stand, to tell which is the "vendor" version 
> nor which is the "centos build" version of the code in git.centos.org. 

While I may be misunderstanding the script, SL devs are contributing 
scripts that look to be able to do this discernment.

> There's not even a tag or branch to indicate it, just a "master" on 
> which changes are accumulating. 

There is no content in master.  The EL7 content is in the c7 branch.

> And it's already gotten polluted. Is the new "centos-git-common" 
> repository part of the official RHEL releases? I think not, but it's 
> in the same environment that formerly contained purely RHEL code. How 
> can we tell future such packages apart?

Commit IDs and the committer name seem to be the only way at present.

> SL did this very well, with the separate "sl6" and "vendors" 
> directories for SRPM's from Scientific Linux, and tools from upstream 
> vendors like Red Hat. A similar separation would have been very 
> welcome at www.centos.org, but somehow, I don't see them resetting the 
> URL's in all their working git clones. 
Yes, it would be welcome to have more traditional separation, but it 
appears that will not happen.  I do reserve the right to be wrong, of 
course.

And I again thank you for a well-reasoned and level response.