Jarek, good morning:

I was unfortunately paged about someone else's hardware problem and
happen to be up.

On Tue, Jul 1, 2014 at 2:54 AM, Jarek Polok <[log in to unmask]> wrote:
> Dear Yasha

>> Are Jerek Polok et al. now Red Hat employees, or still CERN "employees"?
>>
>
> Yes we are CERN employees: the fact of using this or that linux version
> does not change it - why would it ?

Yasha has occasionally been known to spend a great deal of thought in
some very elaborate models of how things work procedurally, that do
not always match what is actually going on. Reviewing or clarifying
the situation can sometimes reveal some interesting points, so it's
not something to begrudge him.

>> Additional questions:
>>
>> A.  Will the SL/SLC source tree for RPM builds be a separate copy from
>> the CentOS git, downloaded therefrom?
>
> I am speaking for SLC here: no: we are going to use CentOS.

There are, for me and for clients I encourage, some very useful
features of SL that CentOS never has and, I think, never will support.
These especially include the various "yum" configurations for third
party repositories, such as EPEL, repoforge, and rpmfusion.

>> A.1  Will the SL/SLC source tree be compared to the original SRPMs that
>> CERN seems to have under license from Red Hat to verify
>> that the CentOS git source is in fact "unadulterated" RHEL 7 source,
>> other than for obvious Red Hat logos and the like?
>>
>
> Speaking for SLC here: yes, we could do it (so could SL and anybody
> else), but please note: this does not change anything for everybody else
> on this list: if somebody decides to distrust Red Hat and CentOS ... why
> would that person trust us ? ...

Because you're aware of the possibly of HTTPS git repositories being
surreptitiously replaced and poisoning all downstream builds. GPG tags
would help that, GPG signed RPM's and SRPM's also help that.

> Why would that "cost" change if you use CentOS (or SL
> built with CentOS sources) ?
>
> Best Regards
>
> Jarek

For me, at least, I'd lose SL's clear separation of 'vendor' and
'non-vendor' code, and the ease of access to and management of the 3rd
paty repositories.