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.