On 06/19/2014 09:16 AM, Nico Kadel-Garcia wrote:
> Take a look at even a simple SPEC file, such as "ntp.spec" to see how 
> much interpretation it's doing. 

Oh, I'm well aware of that.

> Relying on the upstream authors to always do the .spec files *last* 
> with new builds is not necessarily fair, and precludes certain type of 
> code merges. 

While I have no knowledge of the actual workflow at Red Hat, I would 
think that the population into git.centos.org would happen as an 
automated part of the upstream build process, and that what is going in 
to git.centos.org is what rpmbuild is seeing as it builds the 
'canonical' upstream package (or it's being generated by depackaging the 
built SRPM).  This would just about have to be true in order for the 
git.centos.org source to be the actual upstream source.  Anyone with a 
valid subscription should be able to verify this for themselves by 
comparing the git committed source bundle with the subscription access 
SRPM.

This allows excellent change tracking with git (which many many people 
have asked for from CentOS in the past) while still getting the upstream 
source.  Of course, it is a bit of a leap of faith to trust Red Hat to 
do it this way; but, then again, unless you have (or had) a valid 
subscription you couldn't verify that the source RPMs going into 
ftp.redhat.com were the same as what subscribers were getting (in terms 
of package metadata, and even perhaps a different signing key.....etc).  
IMHO, if you don't trust Red Hat to put the correct source into 
git.centos.org then why trust their source at all?  The git commit ID's 
will take care of detecting side-channel modifications after Red Hat's 
populating of the source. (Side note: Linus' choice of the way commit 
ID's were to work is absolutely brilliant.  IMHO).

But I'm curious as to what kind of merge would work with a depackaged 
source RPM but not with the files available through git.centos.org.