Sorry, folks. I wish our release developers well, and hope that they can open up their processes to allow much needed community involvment. But I've hopped to Scientific Linux and find it much more usable due to their willingness to publish updates even without the entire new release bundled, and the much timelier updates from the upstream vendor. php53 and bind97 are directly available for their verison 5.x release, and their version 6.0 has now taken over my testing environments. This makes EPEL's version of drupal, and various Samba 4 testing accessible, and I don't have to waste my time on backports that will be replaced by a release that is further, and further, and further behind.
Perhaps in the future the configuration of the build and patch environments can be opened up, or the patching going on for the package rebundling can be published in just the way people with RHEL would publish their kernel patches, rather than presenting merely the results. But such ideas have been rejected as unnecessary, and even the suggestion was rejected with hostility.
I know very well how much work such projects take, and regret that I was unable to assist further. My tweaks and bundles will now be going over to Fedora and Scientific Linux, rather than here or in the developer's list.
Nico Kadel-Garcia nkadel@gmail.com
On 04/01/2011 09:37 PM, Nico Kadel-Garcia wrote:
Sorry, folks. I wish our release developers well, and hope that they can open up their processes to allow much needed community involvment. But I've hopped to Scientific Linux and find it much more usable due to their willingness to publish updates even without the entire new release bundled, and the much timelier updates from the upstream vendor. php53 and bind97 are directly available for their verison 5.x release, and their version 6.0 has now taken over my testing environments. This makes EPEL's version of drupal, and various Samba 4 testing accessible, and I don't have to waste my time on backports that will be replaced by a release that is further, and further, and further behind.
Perhaps in the future the configuration of the build and patch environments can be opened up, or the patching going on for the package rebundling can be published in just the way people with RHEL would publish their kernel patches, rather than presenting merely the results. But such ideas have been rejected as unnecessary, and even the suggestion was rejected with hostility.
I know very well how much work such projects take, and regret that I was unable to assist further. My tweaks and bundles will now be going over to Fedora and Scientific Linux, rather than here or in the developer's list.
Nico Kadel-Garcia
I would not fault someone for "moving on", but I would when said person does so in a manner that only leads to unhelpful drama.
Anyway, best in the future.
On Fri, 1 Apr 2011, John R Pierce wrote:
On 04/01/11 6:54 PM, Digimer wrote:
I would not fault someone for "moving on", but I would when said person does so in a manner that only leads to unhelpful drama.
yeah, seriously. call the WHAAAAAHmbulance.
I don't see how this is helpful either. But that's the problem, there's no way anyone can help the releases moving forward... Good luck waiting :)
On Sat, 2011-04-02 at 10:31 +0200, Dag Wieers wrote:
On Fri, 1 Apr 2011, John R Pierce wrote:
On 04/01/11 6:54 PM, Digimer wrote:
I would not fault someone for "moving on", but I would when said person does so in a manner that only leads to unhelpful drama.
yeah, seriously. call the WHAAAAAHmbulance.
I don't see how this is helpful either. But that's the problem, there's no way anyone can help the releases moving forward... Good luck waiting :)
Okay, so Nico is a bit upset. I can't say I blame him - But he did raise a point and make me think about something. Now, if I'm wrong, flame the crap out of me, I have very good filter-foo !
The one thing I would love to be able to contribute my time to is helping test new code, and get it out the door so guys on the street can test it out.
Maybe it's my curiosity, but my brain tells me that Fedora is the forerunner for RHEL. And the Fedora code is out there. CentOS is built from the RHEL code, with all RHEL specific items removed. Ergo - If I replicate the build environment on some of my machines, (KVM and XEN both running riot all over my systems, but not doing anything useful for me! :( ), then surley I should be able to get some postive results, and be able to contrib that back to the guys upstream.
That's what my brain tells me. I don't mind running build environments, or test environments or whatever - I guess what I'm saying is GIMME SOME OF YOUR WORKLOAD!!
Or at least make it easy for other bored sysads to help you out. All this spare processing power and capable guys and girls eager to support our distro of choice to get the best bleeding edge stable code. It's almost like following a football team! How DARE debian get ahead of us! Gentoo!? Who the bleeding hell do you think you are!? Don't you know CENTOS is in the HOUSE!?
*calms down* Excuse my excitement. I could edit this email before I hit send, but then you guys wouldn't really know how I feel towards CentOS. How can the average guy get involved with testing, can we build the same environments as you guys? Do you have a standard way of operating that maybe some of us could learn, and contribute? Is it out there already out there and documented? How can we get our hands dirty?
On Monday 04 April 2011 12:25:06 Mister IT Guru wrote:
The one thing I would love to be able to contribute my time to is helping test new code, and get it out the door so guys on the street can test it out.
Before you get flamed-off by people who are already extremely pissed by previous infinity of discussions on this topic, let me try to summarize the answers to your questions, collected from all previous flames that were going on for the past three months. ;-)
Hopefully, my answer could prevent yet another flame starting up... :-)
Also, I am not a developer of CentOS (or of anything else) myself, but just an ordinary user. So I am just going to rehash and summarize what I have read from more knowledgeable people on this list.
Maybe it's my curiosity, but my brain tells me that Fedora is the forerunner for RHEL. And the Fedora code is out there. CentOS is built from the RHEL code, with all RHEL specific items removed. Ergo - If I replicate the build environment on some of my machines,
Herein lies the main problem: *there* *is* *no* *build* *environment* yet. In other words --- the Fedora environment is far too big/generic/unsuitable/whatever (am I right here?), and RedHat is not interested in giving details about their build environment.
So the main problem that CentOS team has to solve with each major release is to construct a build environment that will produce binaries that are bit-by- bit equivalent to official RHEL (up to trademarks, branding and some other stuff).
From my naive understanding, this boils down to the proper order in which packages are supposed to be built. There is more than one possible ordering, and only one will give binary equivalent set of packages.
I am probably oversimplifying things, but it roughly goes as follows:
1) start from some build environment 2) compile the whole distro 3) compare the result bit-by-bit with RHEL binaries 4) if it matches you're done; if it doesn't match, modify the build environment and go back to 1).
AFAIU, the CentOS devs are currently in the above loop. Once they are done, testing will begin and CentOS 6 will probably be released shortly thereafter.
However, nobody knows how much time is it going to take to finish the loop. Not even the devs can estimate that, so better don't ask them! ;-)
I hope that this clears up some things.
(KVM and XEN both running riot all over my systems, but not doing anything useful for me! :( ), then surley I should be able to get some postive results, and be able to contrib that back to the guys upstream.
That's what my brain tells me. I don't mind running build environments, or test environments or whatever - I guess what I'm saying is GIMME SOME OF YOUR WORKLOAD!!
As should be obvious from above, the problem is not in the workload. It's about reverse-engineering the build environment. More computing power (or manpower for that matter) will not help in a significant way.
In general it could help, but the devs need to invest some serious time to train you to do that job, and they don't have the time for that now. It's a good idea to report back with the "gimme some of your workload" statement a couple of months *after* the CentOS 6 is finally out, ie. when the devs do have some free time on their hands to teach you what and how to do. Then you'll be able to help with CentOS 7, for example.
The problem is that after the major release is out, users lose enthusiasm to provide help, and basically nobody wants to invest time to learn and train to build the distro. AFAIK, this is the experience from the time of building of CentOS 5. If I remember what Johnny said about this, out of a whole bunch of people who offered help during the C5 build, *only* *one* was interested to offer his help *after* the build. So people are not consistent in this.
My suggestion to you is to wait for C6 to be finished, and *then* offer your help and time to devs. I bet that they'll get you up to speed with everything you need to know, if you have proper skills to do the job. ;-) Then you could help for the build of CentOS 6.1 when it becomes relevant, or CentOS 7 later on.
Or at least make it easy for other bored sysads to help you out. All this spare processing power and capable guys and girls eager to support our distro of choice to get the best bleeding edge stable code. It's almost like following a football team! How DARE debian get ahead of us! Gentoo!? Who the bleeding hell do you think you are!? Don't you know CENTOS is in the HOUSE!?
*calms down* Excuse my excitement. I could edit this email before I hit send, but then you guys wouldn't really know how I feel towards CentOS. How can the average guy get involved with testing, can we build the same environments as you guys? Do you have a standard way of operating that maybe some of us could learn, and contribute? Is it out there already out there and documented? How can we get our hands dirty?
See above. Also, you can get your hands dirty in other ways (testing, maintaining the website, mailing lists, etc.). Ask on the devel list for TODO jobs that you can help out with.
But don't ask to help with building C6, you're probably too late to offer help there. Instead offer your help in building C7, but early enough so that people can teach you what to do and how to do it.
As a final comment, note that RHEL has put out versions 5.6 and 6 basically simultaneously, so the CentOS devs decided to first build 5.6, and then to go to 6. The logic behind this is that people on 5.5 do need the update to 5.6 as soon as reasonably possible, while noone needs 6 so promptly, so it can wait. That is also one of the reasons why C6 is lagging behind RHEL6 for such a long time (not that there is any sane definition of "long" in this case...).
I sincerely hope that this will answer your questions and prevent yet another escalation of flame on this list... :-)
HTH, :-) Marko
On 04/04/11 10:03 AM, Marko Vojinovic wrote:
So the main problem that CentOS team has to solve with each major release is to construct a build environment that will produce binaries that are bit-by- bit equivalent to official RHEL (up to trademarks, branding and some other stuff).
From my naive understanding, this boils down to the proper order in which
packages are supposed to be built. There is more than one possible ordering, and only one will give binary equivalent set of packages.
I think its even a little worse than this, that various packages require DIFFERENT build environments, toolsets, and so forth.
Marko Vojinovic wrote:
On Monday 04 April 2011 12:25:06 Mister IT Guru wrote:
<snip>
Maybe it's my curiosity, but my brain tells me that Fedora is the forerunner for RHEL. And the Fedora code is out there. CentOS is built from the RHEL code, with all RHEL specific items removed. Ergo - If I replicate the build environment on some of my machines,
Herein lies the main problem: *there* *is* *no* *build* *environment* yet. In other words --- the Fedora environment is far too big/generic/unsuitable/whatever (am I right here?), and RedHat is not interested in giving details about their build environment.
Better explanation is that CentOS project is not building packages, it is *re*building/repackaging packages that Red Hat already built, and they have to be *100%* binary compatible. Fedora environment, "koji", and any other environment are meant for tracking and changing packages. CentOS does not change packages (other then ~5% of .centos. ones), so such environment is practically useless.
So the main problem that CentOS team has to solve with each major release is to construct a build environment that will produce binaries that are bit-by- bit equivalent to official RHEL (up to trademarks, branding and some other stuff).
From my naive understanding, this boils down to the proper order in which
packages are supposed to be built. There is more than one possible ordering, and only one will give binary equivalent set of packages.
I am probably oversimplifying things, but it roughly goes as follows:
- start from some build environment
- compile the whole distro
- compare the result bit-by-bit with RHEL binaries
- if it matches you're done; if it doesn't match, modify the build
environment and go back to 1).
AFAIU, the CentOS devs are currently in the above loop. Once they are done, testing will begin and CentOS 6 will probably be released shortly thereafter.
However, nobody knows how much time is it going to take to finish the loop. Not even the devs can estimate that, so better don't ask them! ;-)
Reverse engineering that is taking place in CentOS project is somewhat stabbing in the dark, trying to find what version of dependency was used to compile the original, and some dependencies used are even from Fedora 6! Try compiling package that could use only one dependency for every package version (and it's every update) from Fedora 6 to 14, and you will get the idea.
For those saying that CentOS devs are slow, take notice that Scientific Linux released SL 6.0, *but* SL 5.6 is still in it's *ALPHA* stage. If too separate teams are close with results, then there is no room for accusations or wondering...
Ljubomir
On Mon, Apr 4, 2011 at 1:36 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
For those saying that CentOS devs are slow, take notice that Scientific Linux released SL 6.0, *but* SL 5.6 is still in it's *ALPHA* stage. If too separate teams are close with results, then there is no room for accusations or wondering...
You're ignoring the fact that SL's already released the 5.6 security updates.
Anyway, as I understand it, this list is for bashing the CentOS devs and not the SL ones!
centos-bounces@centos.org wrote:
On Mon, Apr 4, 2011 at 1:36 PM, Ljubomir Ljubojevic
Anyway, as I understand it, this list is for bashing the CentOS devs and not the SL ones!
bash, ksh, tcsh, zsh and ash are allowed; bash is not required. dash is forbidden because we don't mention Debby Anne nor her domestic partner Suzy here.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Mon, 2011-04-04 at 18:03 +0100, Marko Vojinovic wrote:
On Monday 04 April 2011 12:25:06 Mister IT Guru wrote:
The one thing I would love to be able to contribute my time to is helping test new code, and get it out the door so guys on the street can test it out.
Before you get flamed-off by people who are already extremely pissed by previous infinity of discussions on this topic, let me try to summarize the answers to your questions, collected from all previous flames that were going on for the past three months. ;-)
Hopefully, my answer could prevent yet another flame starting up... :-)
Also, I am not a developer of CentOS (or of anything else) myself, but just an ordinary user. So I am just going to rehash and summarize what I have read from more knowledgeable people on this list.
Maybe it's my curiosity, but my brain tells me that Fedora is the forerunner for RHEL. And the Fedora code is out there. CentOS is built from the RHEL code, with all RHEL specific items removed. Ergo - If I replicate the build environment on some of my machines,
Herein lies the main problem: *there* *is* *no* *build* *environment* yet. In other words --- the Fedora environment is far too big/generic/unsuitable/whatever (am I right here?), and RedHat is not interested in giving details about their build environment.
I think I am beginning to understand. No build environment? *applauds the CentOS devs* Wait does this mean that you use trial and improvement, as you attempt to get to 100% binary compatibility? Awesome
If this is the case, surely that must take a lot of man power? Dev guys - Ask the list for ten minions to do your bidding. I am prepared to become a minion, it would really help if more people had your back when it comes to RHEL doing updates etc. You won't even need to remind the list, you got minions for that!
So the main problem that CentOS team has to solve with each major release is to construct a build environment that will produce binaries that are bit-by- bit equivalent to official RHEL (up to trademarks, branding and some other stuff).
Okay - This makes sense. Do we have a flow chart somewhere online that details this process? Where can assistance be provided? If the CentOS devs can give me a spec on thier build environment, I'm sure I could devise a way to allow others to duplicate the same environment in KVM and help.
From my naive understanding, this boils down to the proper order in which
packages are supposed to be built. There is more than one possible ordering, and only one will give binary equivalent set of packages.
A lot of coffee required here! Woah, serious dev guys, is the workload to this degree? Hey Devs, we *OWE* you! we owe you BIG time, put us to work dammit!
I am probably oversimplifying things, but it roughly goes as follows:
- start from some build environment
- compile the whole distro
- compare the result bit-by-bit with RHEL binaries
- if it matches you're done; if it doesn't match, modify the build
environment and go back to 1).
This is a major achievement for the CentOS devs. Can't we share our spare cycles, and build some sort of bastardised deep blue? Crank together our own grid! *maybe when we hit CentOS 9 or so we will be, here's hoping!*
AFAIU, the CentOS devs are currently in the above loop. Once they are done, testing will begin and CentOS 6 will probably be released shortly thereafter.
However, nobody knows how much time is it going to take to finish the loop. Not even the devs can estimate that, so better don't ask them! ;-)
Time, time time! I don't care how long it takes, so long as it gets done! I have enough faith in previous CentOS builds to be able to wait until the next one is ready. Anyway, I *never* update my production servers until my test rigs are rock solid, and there is at least talk of another update :)
I hope that this clears up some things.
(KVM and XEN both running riot all over my systems, but not doing anything useful for me! :( ), then surley I should be able to get some postive results, and be able to contrib that back to the guys upstream.
That's what my brain tells me. I don't mind running build environments, or test environments or whatever - I guess what I'm saying is GIMME SOME OF YOUR WORKLOAD!!
As should be obvious from above, the problem is not in the workload. It's about reverse-engineering the build environment. More computing power (or manpower for that matter) will not help in a significant way.
Woah, what a way to crush my hopes of a grid of global CentOS systems kicking IBM in the nuts. So to further my understanding, just so that we can maintain binary compatibility with RHEL, the CentOS devs have to hit on by chance a build environment that produces the same output as the equivalent RHEL version.
In general it could help, but the devs need to invest some serious time to train you to do that job, and they don't have the time for that now. It's a good idea to report back with the "gimme some of your workload" statement a couple of months *after* the CentOS 6 is finally out, ie. when the devs do have some free time on their hands to teach you what and how to do. Then you'll be able to help with CentOS 7, for example.
It's a start! I understand that at this point in time they will indeed be busy. Well, in that case, I think I might have to jump on some CentOS devs twitter feeds, so we can keep in touch *hint*
The problem is that after the major release is out, users lose enthusiasm to provide help, and basically nobody wants to invest time to learn and train to build the distro. AFAIK, this is the experience from the time of building of CentOS 5. If I remember what Johnny said about this, out of a whole bunch of people who offered help during the C5 build, *only* *one* was interested to offer his help *after* the build. So people are not consistent in this.
If your a linux admin - it is REALLY good to have this stuff on your CV! I understand that the timing of these questions on the mailing list probably would always come up just as the devs are at their most busiest working on a release. Well I for one hate(love really) the fact that ubuntu gets spoken about all day long. Are you telling me, that of all the full time employed people worked earning only one carried on working, once everything was released? Sounds almost biblical.
Well, I guess the question is, do the CentOS Devs actually *want* assistance in this area? if it would be more of a hindrance, then we need to 'remove' that hindrance. If it's a lack of skills within the CentOS community to actually be able to complete the work, then we need to get some people in that will help. If a dev got hit by a bus, we're screwed!
My suggestion to you is to wait for C6 to be finished, and *then* offer your help and time to devs. I bet that they'll get you up to speed with everything you need to know, if you have proper skills to do the job. ;-) Then you could help for the build of CentOS 6.1 when it becomes relevant, or CentOS 7 later on.
I sure will do. I can admit right now, that no, I do not have the skills to compile a distro, but give me the weblinks and a test rig, and I'll write you a masterpiece! (eventually!) Okay, at least make a contribution.
Or at least make it easy for other bored sysads to help you out. All this spare processing power and capable guys and girls eager to support our distro of choice to get the best bleeding edge stable code. It's almost like following a football team! How DARE debian get ahead of us! Gentoo!? Who the bleeding hell do you think you are!? Don't you know CENTOS is in the HOUSE!?
*calms down* Excuse my excitement. I could edit this email before I hit send, but then you guys wouldn't really know how I feel towards CentOS. How can the average guy get involved with testing, can we build the same environments as you guys? Do you have a standard way of operating that maybe some of us could learn, and contribute? Is it out there already out there and documented? How can we get our hands dirty?
See above. Also, you can get your hands dirty in other ways (testing, maintaining the website, mailing lists, etc.). Ask on the devel list for TODO jobs that you can help out with.
Ah yes! The DEV list? *off to subscribe* I will lurke on here. And I urge others who are even mildly interested in testing, and what Marko said above, to subscribe too, but only talk if your helping! hehe!
But don't ask to help with building C6, you're probably too late to offer help there. Instead offer your help in building C7, but early enough so that people can teach you what to do and how to do it.
I'm off to join the dev list to do just this.
As a final comment, note that RHEL has put out versions 5.6 and 6 basically simultaneously, so the CentOS devs decided to first build 5.6, and then to go to 6. The logic behind this is that people on 5.5 do need the update to 5.6 as soon as reasonably possible, while noone needs 6 so promptly, so it can wait. That is also one of the reasons why C6 is lagging behind RHEL6 for such a long time (not that there is any sane definition of "long" in this case...).
The above is just common sense, no one should really complain about that! How many times have we been asked by a manager to do two workloads at once, and how much do we actually achieve? So "lay off the DEVS, they have buckets of work to do as it is! And be happy with 5.5 dammit!!"
I sincerely hope that this will answer your questions and prevent yet another escalation of flame on this list... :-)
HTH, :-) Marko
Thank you Marko, and others that replied too. I'll only reply to this response but I did read, and I appreciate the comments in this thread. I just want to see CentOS everywhere, and be an expert in it :)
On 04/01/2011 09:37 PM, Nico Kadel-Garcia wrote:
Sorry, folks. I wish our release developers well, and hope that they can open up their processes to allow much needed community involvment. But I've hopped to Scientific Linux and find it much more usable due to their willingness to publish updates even without the entire new release bundled, and the much timelier updates from the upstream vendor. php53 and bind97 are directly available for their verison 5.x release, and their version 6.0 has now taken over my testing environments. This makes EPEL's version of drupal, and various Samba 4 testing accessible, and I don't have to waste my time on backports that will be replaced by a release that is further, and further, and further behind.
Perhaps in the future the configuration of the build and patch environments can be opened up, or the patching going on for the package rebundling can be published in just the way people with RHEL would publish their kernel patches, rather than presenting merely the results. But such ideas have been rejected as unnecessary, and even the suggestion was rejected with hostility.
I know very well how much work such projects take, and regret that I was unable to assist further. My tweaks and bundles will now be going over to Fedora and Scientific Linux, rather than here or in the developer's list.
Big issue I saw with Scientific Linux was a lack of commitment to long term support matching what RedHat and Centos provide.
My $.02 Steve Clark
On 3.4.2011 23:57, Steve Clark wrote:
Big issue I saw with Scientific Linux was a lack of commitment to long term support matching what RedHat and Centos provide.
This seems to be true.
https://access.redhat.com/support/policy/updates/errata/ https://www.scientificlinux.org/distributions/
Assuming that CentOS is supporting as long as RedHat:
CentOS 5 until March 31, 2014 SL 5 until at least 2012-02-02
CentOS 6 until November 30, 2017 SL 6 until at least 2014-11-11
On 04/04/2011 06:47 AM, Markus Falb wrote:
On 3.4.2011 23:57, Steve Clark wrote:
Big issue I saw with Scientific Linux was a lack of commitment to long term support matching what RedHat and Centos provide.
This seems to be true.
https://access.redhat.com/support/policy/updates/errata/ https://www.scientificlinux.org/distributions/
Assuming that CentOS is supporting as long as RedHat:
CentOS 5 until March 31, 2014 SL 5 until at least 2012-02-02
CentOS 6 until November 30, 2017 SL 6 until at least 2014-11-11 tp://lists.centos.org/mailman/listinfo/centos
From the Scientic WebPage " Minor Releases Scientific Linux has plans to make a minor release based on each of the Enterprise Updates for the latest major release. Minor releases for the older major releases will occur much less frequently. So for the Scientific Linux 3.0.x line, we will make minor releases for each Enterprise Update, until Scientific Linux 4.0.x is released. We will then make the 4.0.x minor releases for each of the Enterprise 4 Updates, and only occasionally create a minor release for the 3.0.x line. The minor releases will be named according to their corresponding update release. Hence, Scientific Linux 3.0.1 corresponded with Update 1, 3.0.2 will correspond with Update 2. The minor releases will also be a time for the installer to be enhanced, programs to be added or removed, and other minor tweeking. Administrators should be able to use yum or apt to get from one minor release to another, without much hassle. "
I read this as not being keeping up with minor releases.
-
Brunner, Brian T. -
Dag Wieers -
Digimer -
John R Pierce -
Ljubomir Ljubojevic -
Marko Vojinovic -
Markus Falb -
Mister IT Guru -
Nico Kadel-Garcia -
Steve Clark -
Tom H