On 07/01/2014 11:16 AM, Patrick J. LoPresti wrote:
> On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen <[log in to unmask]> wrote:
>>
>> ??? That is not at all what I got from his reply.  What I got was that CERN
>> will still be committing resources, but instead of duplicating effort
>> they're joining up with the CentOS effort.
> Whatever.

Well, apparently I understood Jarek's post correctly.

>   The relevant questions are: (1) Will SL's goal continue to
> be creating a re-spin of Red Hat Enterprise and *not* CentOS, since
> Red Hat's clear goal in acquiring CentOS is to create divergence
> between the two;

It would be detrimental to their bottom line to do so, since so many 
people are out there who could potentially blow the whistle on any such 
divergence.

>   and (2) what mechanism(s) will SL use to achieve that
> goal? (Specifically, will SL compare the git sources against actual
> SRPMs obtained via subscription?)

If the SL developers want to reply, they will.  I trust Connie and all 
the rest are working on the situation, and I trust their judgement for 
their project.

> The *goal* of CentOS used to be binary compatibility, even if it was 
> never 100% achieved. 

What matters is what they intended it to mean, which has never been 'bit 
for bit identical.'  What does 'binary compatibility' really mean?  (I 
take it to mean that all software compiled and linked for one will run 
on the other; and that doesn't require the packages to be anywhere close 
in terms of a binary compare; the CentOS test includes more than that.)  
The following post from 2011 points to the info on how the CentOS 
project has historically done the binary compatibility test: 
http://lists.centos.org/pipermail/centos/2011-April/109483.html (the 
actual script has been moved to vault; see 
http://vault.centos.org/4.9/build/distro/tmverifyrpms for the actual 
script, dated March 10, 2011).

Further, '100% binary compatibility' to me means that 100% of the 
software built for one will run absolutely unmodified with identical 
behavior on both systems (the binaries built on one are 100% compatible 
with the other).  Compatible doesn't mean and has never meant identical 
at the byte for byte compare level.

...
>> No one yet in this thread has provided a public, no
>> login required, link to up-to-date sources for SLES 11.
> Yes, you keep bringing this up as if it were an argument.

It's a valid counter-example.  If the violation of not publicly 
releasing source RPMS and tying subscription status with continued 
access were so egregious then SuSE would have been sued into oblivion 
long ago, and the absence of such suits makes it more difficult for the 
argument to be made that Red Hat, which is making up-to-date sources 
available, is violating where SuSE is not (which does not make 
up-to-date sources available).