On 04/12/2011 07:24 AM, Dag Wieers wrote:
> On Tue, 12 Apr 2011, Johnny Hughes wrote:
>
>> On 04/11/2011 05:07 PM, Dag Wieers wrote:
>>> On Mon, 11 Apr 2011, Les Mikesell wrote:
>>>> On 4/11/2011 4:02 PM, Ned Slider wrote:
>>>>> On 11/04/11 20:16, Digimer wrote:
>>>>>>
>>>>>> /putting on asbestos pants.
>>>>>>
>>>>>> each release is more complex than the last. The web of dependency grows,
>>>>>> so the reverse-engineering takes longer and longer.
>>>>>>
>>>>>
>>>>> This is just complete nonsense. You clearly have no understanding of the
>>>>> processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer
>>>>> anything, they simply rebuild the upstream sources. It's not rocket science.
>>>>
>>>> It's not simple... They don't ship until they reproduce something that
>>>> they consider 'binary compatible' to the upstream binaries, which
>>>> depends on a build environment containing some things that don't match
>>>> the sources. Some of this is documented for the similar SL build but
>>>> they aren't as picky about library linkage versions (which may not
>>>> matter functionally anyway).
>>>
>>> It's unfair to Scientific Linux to imply that Scientific Linux does not
>>> care about compatibility. The issues reported on this list by Johnny to
>>> discredit SL were found in the 5.6 alpha release, already fixed by SL and
>>> improperly used to discredit SL.
>>>
>>> Johnny found those packages when comparing his own build-issues against
>>> Scientific's Linux release, while the Scientific Linux project has no such
>>> means to do the same because CentOS does not provide public alpha and beta
>>> releases.
The issue is that people are using those releases in production and
claiming that they are "production ready". Whether that is the
intention of the SL team or not, that is what is happening. People get
on these lists and claim that those packages are the security updates
from SL and that they have "released before CentOS" because they exist.
They are instead Beta or Alpha and should not be used in production
(IMHO) ... but everyone gets to control their own servers.
The CentOS team does not think that is the best approach. We do not
think that packages floating around in the general public with the same
EVR that will be released in final form (as we can not change the EVR
for the vast majority of our packages) is the way to go. Because of
this, the QA process is controlled, not closed. You control submission
to your repos ... not everyone can submit directly into your build
system. Not everyone can sign your packages.
>>>
>>> It's one thing to find an issue in a competing product, but it's another
>>> to bring it up on this mailinglist to discredit a competing product
>>> (just because it is truly open and has a public alpha release).
>>>
>>> CentOS obviously looks at how Scientific Linux is fixing issues, but
>>> keeping their own fixes secret.
SL did not tell me anything about their packages ... I looked at their
RPM and their SRPM. I looked at the Oracle RPM and SRPM. I looked at
the RHEL RPM and SRPM. I looked at the Red Hat bugzilla. Akemi Yagi
also looked at the RH bugzilla and found the issue. The issue is a leap
year issue. A test fails because there is an extra day in a calculation
after Feb 28th 2011 that is not there before that date if you build the
package.
>>>
>>> PS The notion that Scientific Linux does not care about compatbility is a
>>> false claim and it needs to stop.
>>>
>>
>> I did not do anything to discredit anyone and I take exception to that term.
>>
>> I published an example of WHY CentOS does not release anything until we
>> check it via QA. Once something is released, it can not "come back".
>
> Johnny, you are right. I have to apologize for those remarks, they were
> out of line. Still the notion exists (and has been repeated) that
> Scientific Linux does not care about binary compatibility. Even if this
> was not what you intended.
>
>
And I have posted several times about this. What SL does do is they
publish lots of things on their main ISOs and tree that are not part of
the upstream distro. That can be either good or bad, depending on your
point of view. My personal opinion on the matter is that at install
time, you should stay within the same universe of packages to the
maximum extent practical. In CentOS-2,3, and 4 we added yum {and the
necessary dependencies} when they were not in the upstream distro, so we
do it as well ... however, I personally think that should be minimized.
>> What I said was what CentOS does if we have a problem (look at other
>> distros to see if they have the same problem).
>
> But you have to agree that Scientific Linux does not have that (reverse)
> privilege.
I do not agree with that. They can look at anything we release, just
like I can look at anything they release, anything oracle releases, or
anything upstream releases. We have an obligation to minimize putting
things out there that are wrong. We provided the QA team with access to
an initial 5.6 tree a very long time ago. (The first packages showed up
there in QA for initial testing on January 26, 2011 ... and we finally
got a release on April 8, 2011).
Also, both Connie and Troy are more than welcome to be members of the
CentOS QA team. In fact, at one time Connie was a member of the CentOS
QA team. We appreciate the fact that they may not have time to do this
and build their distro too, so we don't expect them to do so, but they
could if they wanted to.
>
>
>> And I have known that all of YOUR concern about the process has always
>> been so you can try to steal our users Dag. If you want to steal our
>> users for your rebuild then you can do that.
>
> There is no such rebuild at this time. That twitter message was started
> with 'Wouldn't it be nice...', but I ran out of 140 characters to make a
> statement :)
>
> I was surprised by the reaction though, although I won't be able to pull
> that off by myself, hopefully I can add my support to such a project. Even
> when being part of the team I have stated that the best thing that could
> happen to CentOS is more competition, and I still stand by that.
>
> I know you have been telling people to roll their own too.
>
If people want to roll their own, they can. I have provided all the
information for them to do that in several posts.
I encourage them to do it (if for no other reason than a learning
experience). I then encourage them to think about how they can scale a
delivery system so it can run on 29% of the world's Linux servers, and
how they can maintain that "delivery system" of hundreds of machines to
provide a distro to millions of users.
We have an obligation to the "hardware providers" as well, to
control/minimize the access to the machines they donate so that they are
used only for what the donors intend.
You have said yourself that only you will sign your rpmforge packages.
You also understand the need to control some things close to the vest.
I have to use this (CentOS) in production, it has to be right. We do
not want bad packages floating around out there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20110412/b9ce552d/attachment-0005.sig>