On 05/07/2011 09:00 AM, Benjamin Smith wrote:
I was wondering what feedback might be offered by the CentOS community on their experiences using Scientific Linux?
I'm a long-time Centos user, and am basically happy with CentOS. I understand there are delays getting EL 6 out. We have been long anxious to roll out EL 6 as soon as it's ready, but our time window for rollout is looming and we will need to act. (for business reasons, we need to rollout over summer, before Aug 1, we need to start regression testing now!)
I was once a WhiteBox Enterprise Linux user and switched to CentOS 4 without issue, and am assuming that I might need to do something similar if we decide to go this route.
Any feedback is appreciated!
I had to complete a new VM Host machine before CentOS-6 was ready, so I used SL-6 as the underpinnings. It simply worked, once I ironed out a couple of unrelated hardware issues. It auto-updates and lets me know when that's been done, but it doesn't reboot unless I want to, so there's little risk in allowing the updates. Auto-update can be disabled if you prefer.
So far it has been flawless. It's managing two very large software RAID-6 arrays and 7 Guest VMs on a dual-Xeon Supermicro motherboard.
All of the VM Guest OS's are CentOS-5.6 which works well for my applications. I may or may not upgrade the Guests to C6, depending on need. CentOS has been so reliable that I'm reluctant to move to a different platform. I've used Ubuntu Server and it works well, but I'm more familiar with the RHEL way of doing things so I'll stick with CentOS.
One thing I don't know much about is an in-place upgrade of C5 to C6. There are some under-the-hood differences that must be taken into account, which I haven't looked into.
YMMV, Chuck
Chuck Munro wrote:
On 05/07/2011 09:00 AM, Benjamin Smith wrote:
I was wondering what feedback might be offered by the CentOS community on their experiences using Scientific Linux?
I'm a long-time Centos user, and am basically happy with CentOS. I understand there are delays getting EL 6 out. We have been long anxious to roll out EL 6 as soon as it's ready, but our time window for rollout is looming and we will need to act. (for business reasons, we need to rollout over summer, before Aug 1, we need to start regression testing now!)
I was once a WhiteBox Enterprise Linux user and switched to CentOS 4 without issue, and am assuming that I might need to do something similar if we decide to go this route.
Any feedback is appreciated!
I had to complete a new VM Host machine before CentOS-6 was ready, so I used SL-6 as the underpinnings. It simply worked, once I ironed out a couple of unrelated hardware issues. It auto-updates and lets me know when that's been done, but it doesn't reboot unless I want to, so there's little risk in allowing the updates. Auto-update can be disabled if you prefer.
So far it has been flawless. It's managing two very large software RAID-6 arrays and 7 Guest VMs on a dual-Xeon Supermicro motherboard.
All of the VM Guest OS's are CentOS-5.6 which works well for my applications. I may or may not upgrade the Guests to C6, depending on need. CentOS has been so reliable that I'm reluctant to move to a different platform. I've used Ubuntu Server and it works well, but I'm more familiar with the RHEL way of doing things so I'll stick with CentOS.
One thing I don't know much about is an in-place upgrade of C5 to C6. There are some under-the-hood differences that must be taken into account, which I haven't looked into.
YMMV, Chuck
in-place upgrade of C5 to C6 will be most likely impossible. To many changes of how thing work.
Ljubomir
On Sat, 7 May 2011, Ljubomir Ljubojevic wrote:
in-place upgrade of C5 to C6 will be most likely impossible. To many changes of how thing work.
In local testing built from the anaconda and related sources that will become CentOS 6, the offer to upgrade an existing install is made during a media based install. As I was not interested in upgrading a random drive pulled from my 'scratch pool', I did a wipe and fresh partition and install ;)
Particularly difficult to me seems to be the 'ext4' conversion from lower numbered versions with an 'in place' upgrade
-- Russ herrold
On Saturday, May 07, 2011 11:52:21 AM Ljubomir Ljubojevic wrote:
in-place upgrade of C5 to C6 will be most likely impossible. To many changes of how thing work.
Thankfully, the only in-place upgrades I'll really consider is to cross-grade SL6 to C6. I've started testing with SL6 and will happily report to everyone how the cross-grade goes as soon as C6 is out!
-Ben
Le 09/05/2011 18:36, Benjamin Smith a écrit :
On Saturday, May 07, 2011 11:52:21 AM Ljubomir Ljubojevic wrote:
in-place upgrade of C5 to C6 will be most likely impossible. To many
changes of how thing work.
Thankfully, the only in-place upgrades I'll really consider is to cross-grade SL6 to C6. I've started testing with SL6 and will happily report to everyone how the cross-grade goes as soon as C6 is out!
-Ben
Hi,
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Alain
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Alain
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
Ljubomir
On Tue, 10 May 2011, Ljubomir Ljubojevic wrote:
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
On Wed, 2011-05-11 at 03:12 +0200, Dag Wieers wrote:
On Tue, 10 May 2011, Ljubomir Ljubojevic wrote:
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
---- exactly, and there are additional packages in 6.1 that weren't ready when 6.0 was released.
Craig
On 05/10/2011 08:19 PM, Craig White wrote:
On Wed, 2011-05-11 at 03:12 +0200, Dag Wieers wrote:
On Tue, 10 May 2011, Ljubomir Ljubojevic wrote:
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
exactly, and there are additional packages in 6.1 that weren't ready when 6.0 was released.
Craig
A couple of packages added to the list is not the same as a ZERO point release with no build system. Upstream is now building on a released 6.0 tree ... before they were building on a hodge podge mix that was only in their proprietary build system and nowhere else. On top of that upstream as packages in a optional channel that is not on any ISO set and not easy to obtain for checking purposes.
Most of these problems will not be encountered on the NEXT build.
On 05/10/2011 08:12 PM, Dag Wieers wrote:
On Tue, 10 May 2011, Ljubomir Ljubojevic wrote:
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
On Thu, May 12, 2011 at 04:05:57AM -0500, Ron Blizzard wrote:
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
Amnesia of opportunity, perhaps? Or perhaps it's even simpler in that it doesn't suit their end goals to remember.
John
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
---- I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
But you need to also calculate time elapsed between date of Distribution Release and date of release of SRPMS for 6.0. Am I correct that it took a month for SRPMS to be released?
Ljubomir
On Thu, May 12, 2011 at 8:55 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
• 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
But you need to also calculate time elapsed between date of Distribution Release and date of release of SRPMS for 6.0. Am I correct that it took a month for SRPMS to be released?
Apparently not, according to:
http://lists.centos.org/pipermail/centos-devel/2010-November/006025.html
But, yes, there are a few missing srpms even as of now ...
Akemi
On Thu, May 12, 2011 at 4:41 PM, R P Herrold herrold@owlriver.com wrote:
On Thu, 12 May 2011, Akemi Yagi wrote:
But, yes, there are a few missing srpms even as of now ...
bug number please
Jeff_S knows. He filed a bunch at upstream bugzilla requesting the release of missing srpms.
Akemi
On Thu, 12 May 2011, Akemi Yagi wrote:
On Thu, May 12, 2011 at 4:41 PM, R P Herrold herrold@owlriver.com wrote:
On Thu, 12 May 2011, Akemi Yagi wrote:
But, yes, there are a few missing srpms even as of now ...
bug number please
Jeff_S knows. He filed a bunch at upstream bugzilla requesting the release of missing srpms.
upstream unreleased SRPMs are a different kettle of fish -- I mis-understood you to be indicating that the CentOS SRPM rollout was incomplete. My error
Thank you
-- Russ herrold
On 05/12/2011 10:09 AM, Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
The ZERO release is always going to take longer than the others.
The Original CentOS 3 release did not even have a ZERO release. We didn't finish it until 3.1 had been out for some time and we released 3.1 as our first release.
That first release happened (for 3.1) on 3.19.2004: http://lists.centos.org/pipermail/centos/2004-March/000015.html
The Red Hat 3.0 release happened on October 23, 2003.
That is 5 months.
The 4.0 release cycle and the 5.0 release cycle was much better because the Beta and RC releases were much closer in time and content to the actual released ISOs and we were able to build the first release version on our beta.
This is NOT the case with 6.0. First off, we can not use any of the existing infrastructure to build on because we can not build on a CentOS 4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs themselves.
Secondly, the distribution will not build on the Beta (much like the 3.x release and UNLIKE the 4.0 and 5.0 releases). Not only that, but upstream used many "non released" packages to build on ... packages we can not see or get.
Now, because of those things and because we choose to stop work on 6.0 to build out 5.6 and 4.9, the 6.0 release is late.
We do not need a discussion of how bad CentOS sucks every week on this list.
If you like CentOS, use it ... if you like SL then use that.
This list is for the CentOS distribution .. it is not for how to use SL or how to migrate to SL. SL is a great product and if people want to use it then I am all for it ... however, talk about it on their mailing list, not ours.
On 05/12/2011 05:49 PM, Johnny Hughes wrote:
On 05/12/2011 10:09 AM, Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradburymark.bradbury@gmail.com wrote:
This is NOT the case with 6.0. First off, we can not use any of the existing infrastructure to build on because we can not build on a CentOS 4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs themselves.
And changing compression payload to XZ.
[...snip...]
We do not need a discussion of how bad CentOS sucks every week on this list.
+1, It makes following the list harder and time consuming for both centos users and developers.
On Thu, 12 May 2011, Johnny Hughes wrote:
On 05/12/2011 10:09 AM, Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
The ZERO release is always going to take longer than the others.
Past numbers debunks this myth:
CentOS 4.0 took 23 days
CentOS 5.0 took 28 days
CentOS 6.0 is not released after 6 months.
While eg.
CentOS 4.8 took 3 months
CentOS 5.6 took 3 months
See also:
http://en.wikipedia.org/wiki/CentOS
On Mon, May 16, 2011 at 2:44 AM, Dag Wieers dag@wieers.com wrote:
On Thu, 12 May 2011, Johnny Hughes wrote:
The ZERO release is always going to take longer than the others.
Past numbers debunks this myth:
CentOS 4.0 took 23 days
CentOS 5.0 took 28 days
CentOS 6.0 is not released after 6 months.
You left out and failed to respond to the following explanations.
From Johnny Hughes earlier response:
~~ The ZERO release is always going to take longer than the others.
The Original CentOS 3 release did not even have a ZERO release. We didn't finish it until 3.1 had been out for some time and we released 3.1 as our first release.
That first release happened (for 3.1) on 3.19.2004: http://lists.centos.org/pipermail/centos/2004-March/000015.html
The Red Hat 3.0 release happened on October 23, 2003.
That is 5 months.
The 4.0 release cycle and the 5.0 release cycle was much better because the Beta and RC releases were much closer in time and content to the actual released ISOs and we were able to build the first release version on our beta.
This is NOT the case with 6.0. First off, we can not use any of the existing infrastructure to build on because we can not build on a CentOS 4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs themselves.
Secondly, the distribution will not build on the Beta (much like the 3.x release and UNLIKE the 4.0 and 5.0 releases). Not only that, but upstream used many "non released" packages to build on ... packages we can not see or get.
Now, because of those things and because we choose to stop work on 6.0 to build out 5.6 and 4.9, the 6.0 release is late. ~~
Note, the reasons why 4.0 and 5.0 *could* be released more quickly:
"The 4.0 release cycle and the 5.0 release cycle was much better because the Beta and RC releases were much closer in time and content to the actual released ISOs and we were able to build the first release version on our beta."
And why 6.0 (like 3.0) is a different "animal."
"This is NOT the case with 6.0. First off, we can not use any of the existing infrastructure to build on because we can not build on a CentOS 4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs themselves.
"Secondly, the distribution will not build on the Beta (much like the 3.x release and UNLIKE the 4.0 and 5.0 releases). Not only that, but upstream used many "non released" packages to build on ... packages we can not see or get."
And also the fact that two point releases also came out in the same time frame:
"Now, because of those things and because we choose to stop work on 6.0 to build out 5.6 and 4.9, the 6.0 release is late."
Why do you snip the explanations and ignore the arguments contained in the text you snipped? Why no mention of the time it took to get 3.1 (not 3.0) out the door? Why constantly cast CentOS in the darkest possible light?
On Mon, 16 May 2011, Ron Blizzard wrote:
On Mon, May 16, 2011 at 2:44 AM, Dag Wieers dag@wieers.com wrote:
On Thu, 12 May 2011, Johnny Hughes wrote:
The ZERO release is always going to take longer than the others.
Past numbers debunks this myth:
CentOS 4.0 took 23 days
CentOS 5.0 took 28 days
CentOS 6.0 is not released after 6 months.
Why do you snip the explanations and ignore the arguments contained in the text you snipped? Why no mention of the time it took to get 3.1 (not 3.0) out the door?
CentOS 3.0 was not released because the project was still in its infancy (cAos project). I don't think it makes sense to even use it as a point of reference (unless maybe to argue for a direct CentOS 6.1 release).
But that still makes Johnny's statement false by a large margin.
"The ZERO release is always going to take longer than the others."
Also the whole explanation does not provide any reasoning why CentOS 5.6 took 3 months. The QA team is not allowed to speak up or provide feedback, or they could loose their 'privilege'.
Sure CentOS 6.0 is a different beast, but CentOS 6.0 was delayed in favor of CentOS 5.6. So again, why would CentOS 6.1 be released quicker if CentOS 5.6 has a well-known process and non of the issues Johnny was pointing at ?
My question was very specific though.
Why constantly cast CentOS in the darkest possible light?
I don't think that's what I am doing. I commended Johnny for his very quick CentOS 4.9 release, but I honestly can not praise a release that is 3 months or 6 months late (with no transparency to what is going on or how we could help).
But if anything brought up wouldn't be ignored or obfuscated, CentOS communication would be a lot more honest, and threads would be a lot shorter. It's because the discussion is being side-tracked that they are becoming larger and the essence is being repeated.
There was a recent thread on centos-devel which clearly demonstrated this. It took a long thread and real worls examples for the CentOS developers to finally acknowledge there was a problem, and acknowledge it could be fixed for CentOS 6. This thread could be 4 posts long if the response wouldn't be defensive by default.
(And just like this thread, I did not start it either and am hardly the largest contributor to the thread)
On Mon, May 16, 2011 at 11:32:15AM +0200, Dag Wieers wrote:
On Mon, 16 May 2011, Ron Blizzard wrote:
Why constantly cast CentOS in the darkest possible light?
I don't think that's what I am doing. I commended Johnny for his very quick CentOS 4.9 release, but I honestly can not praise a release that is 3 months or 6 months late (with no transparency to what is going on or how we could help).
You've been doing it for months. It's getting quite old and tiresome.
John
On 05/16/2011 04:32 AM, Dag Wieers wrote:
On Mon, 16 May 2011, Ron Blizzard wrote:
On Mon, May 16, 2011 at 2:44 AM, Dag Wieers dag@wieers.com wrote:
On Thu, 12 May 2011, Johnny Hughes wrote:
The ZERO release is always going to take longer than the others.
Past numbers debunks this myth:
CentOS 4.0 took 23 days CentOS 5.0 took 28 days CentOS 6.0 is not released after 6 months.Why do you snip the explanations and ignore the arguments contained in the text you snipped? Why no mention of the time it took to get 3.1 (not 3.0) out the door?
CentOS 3.0 was not released because the project was still in its infancy (cAos project). I don't think it makes sense to even use it as a point of reference (unless maybe to argue for a direct CentOS 6.1 release).
But that still makes Johnny's statement false by a large margin.
"The ZERO release is always going to take longer than the others."Also the whole explanation does not provide any reasoning why CentOS 5.6 took 3 months. The QA team is not allowed to speak up or provide feedback, or they could loose their 'privilege'.
Sure CentOS 6.0 is a different beast, but CentOS 6.0 was delayed in favor of CentOS 5.6. So again, why would CentOS 6.1 be released quicker if CentOS 5.6 has a well-known process and non of the issues Johnny was pointing at ?
This was mainly because we had to rewrite anaconda a bunch of times to get the ISOs to build. It was also because we kept finding issues in QA. (package A need to be rebuilt, which caused package B to be rebuilt).
We added in QA at the request of the Community ... and it helps. It also makes it take longer to get a release out. That and, our developers do this in their spare time.
Take a look at why samba says Samba4 is not out:
===================================== When will Samba 4.0.0 be released?
When it's ready. It's very hard to say when that will be. It depends on a lot of things and people's spare time. =====================================
My question was very specific though.
Your question is insulting and arrogant. If you want to use CentOS, then use it. If you don't then take your arrogant whining somewhere else.
Why constantly cast CentOS in the darkest possible light?
I don't think that's what I am doing. I commended Johnny for his very quick CentOS 4.9 release, but I honestly can not praise a release that is 3 months or 6 months late (with no transparency to what is going on or how we could help).
You can't help ... we tried to let you help. You don't want to help. You want to stir the pot. That you don't like the project is obvious. Go away.
But if anything brought up wouldn't be ignored or obfuscated, CentOS communication would be a lot more honest, and threads would be a lot shorter. It's because the discussion is being side-tracked that they are becoming larger and the essence is being repeated.
There was a recent thread on centos-devel which clearly demonstrated this. It took a long thread and real worls examples for the CentOS developers to finally acknowledge there was a problem, and acknowledge it could be fixed for CentOS 6. This thread could be 4 posts long if the response wouldn't be defensive by default.
We want to produce a quality product. We have been doing so for 7 years. If it is not fast enough for you, then don't use it.
(And just like this thread, I did not start it either and am hardly the largest contributor to the thread)
On 05/16/2011 02:44 AM, Dag Wieers wrote:
On Thu, 12 May 2011, Johnny Hughes wrote:
On 05/12/2011 10:09 AM, Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
> Do you expect the C6.0 -> C6.1 differences to be more complex, or less > complex than the C5.5 -> C5.6 differences ? > > And given that C5.6 took 3 months, are there any reasons why C6.1 would > take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
The ZERO release is always going to take longer than the others.
Past numbers debunks this myth:
CentOS 4.0 took 23 days CentOS 5.0 took 28 days CentOS 6.0 is not released after 6 months.While eg.
CentOS 4.8 took 3 months CentOS 5.6 took 3 monthsSee also:
http://en.wikipedia.org/wiki/CentOS
Yes, and I told you why that is ... upstream had good beta/rc programs for those c4.0 and c5.0. The releases were built entirely on the beta's ... the build environment was good.
For 3.0 and 6.0, we had to invent a new build system and had to host it on a different OS. They did not build it on the beta/rc.
It will be released when it is released, if you don't like it then leave.
On Mon, 16 May 2011, Johnny Hughes wrote:
It will be released when it is released, if you don't like it then leave.
Before I leave this list let me take you back about 7 years to the Whitebox mailinglist. You may not remember that Whitebox had a list of issues of its own, no timely updates, no community effort, lack of good communication. It was mostly a one-man-effort.
And the people on that list who were not pleased, included Johnny and Karanbir. And it's striking (and ironic) how similar the discussions went 7 years ago. Johnny said:
[WBEL-users] WBEL Vs Centos ? :-S http://beau.org/pipermail/whitebox-users/2004-December/004761.html
"If timely updates are not a key factor for you, then WBEL is a great distro. If timely updates are the most important thing you consider about the distro you want, then WBEL might not be a fit for you. That is all I have ever said ... and I have never said it meanly."
or:
[WBEL-users] WBEL Vs Centos ? :-S http://beau.org/pipermail/whitebox-users/2004-December/004740.html
"I just think people should not have the expectation the WBEL is community operated, it is not. It's NOT like debian or gentoo where others can get involved. I know, I tried really hard to do so many times.
Karanbir said:
[WBEL-users] WBEL ...dead? http://beau.org/pipermail/whitebox-users/2004-December/004684.html
"Be a lil difficult to sell that to the IT Manager / CTO : Hang tight dude, its comming. Anytime now."
or:
[WBEL-users] WBEL ...dead? http://beau.org/pipermail/whitebox-users/2004-December/004709.html
"Why ? the other RHEL recompiles dont have this 'its coming, hang on' attitude do they ?
If there is a security issue out there, you can put in a fairly good idea as to when its possible to deploy with them. Whats the scene with WBEL ?"
The only difference I see is that back then Whitebox had only a fraction of users, and even less using it for critical mission, while nowadays people rely even more on timely security updates and releases coming from CentOS. And people expect to help and contribute to the process to make that happen.
Which, contrary to what is stated now, was an essential part in the start and growth of the CentOS project.
Anyay, goodbye and thanks for all the fish !
On Thu, 2011-05-19 at 13:54 +0200, Dag Wieers wrote:
On Mon, 16 May 2011, Johnny Hughes wrote:
It will be released when it is released, if you don't like it then leave.
Before I leave this list let me take you back about 7 years to the Whitebox mailinglist. You may not remember that Whitebox had a list of issues of its own, no timely updates, no community effort, lack of good communication. It was mostly a one-man-effort.
<snip>
Anyay, goodbye and thanks for all the fish !
Sorry to see you go, Dag. Your technical input to this list over the years has, IMHO, been valuable. And whether or not I agreed with your opinion input, it was always presented in a professional manner.
This is my first, and last, post to this line of threads, but frankly, I have greater concern for the lack of professionalism shown by some on this list in the last few months than the timeliness, or lack thereof, of updates.
IMHO, personal attacks and profanity directed at any list member is always grossly inappropriate.
Thanks for your contributions.
B.J.
RHEL 6.0, Linux 2.6.32-71.29.1.el6.x86_64
On Thu, 2011-05-19 at 13:54 +0200, Dag Wieers wrote:
On Mon, 16 May 2011, Johnny Hughes wrote:
It will be released when it is released, if you don't like it then leave.
Before I leave this list let me take you back about 7 years to the Whitebox mailinglist. You may not remember that Whitebox had a list of issues of its own, no timely updates, no community effort, lack of good communication. It was mostly a one-man-effort.
And the people on that list who were not pleased, included Johnny and Karanbir. And it's striking (and ironic) how similar the discussions went 7 years ago. Johnny said:
[WBEL-users] WBEL Vs Centos ? :-S http://beau.org/pipermail/whitebox-users/2004-December/004761.html
"If timely updates are not a key factor for you, then WBEL is a great distro. If timely updates are the most important thing you consider about the distro you want, then WBEL might not be a fit for you. That is all I have ever said ... and I have never said it meanly."
or:
[WBEL-users] WBEL Vs Centos ? :-S http://beau.org/pipermail/whitebox-users/2004-December/004740.html
"I just think people should not have the expectation the WBEL is community operated, it is not. It's NOT like debian or gentoo where others can get involved. I know, I tried really hard to do so many times.
Karanbir said:
[WBEL-users] WBEL ...dead? http://beau.org/pipermail/whitebox-users/2004-December/004684.html
"Be a lil difficult to sell that to the IT Manager / CTO : Hang tight dude, its comming. Anytime now."
or:
[WBEL-users] WBEL ...dead? http://beau.org/pipermail/whitebox-users/2004-December/004709.html
"Why ? the other RHEL recompiles dont have this 'its coming, hang on' attitude do they ?
If there is a security issue out there, you can put in a fairly good idea as to when its possible to deploy with them. Whats the scene with WBEL ?"
The only difference I see is that back then Whitebox had only a fraction of users, and even less using it for critical mission, while nowadays people rely even more on timely security updates and releases coming from CentOS. And people expect to help and contribute to the process to make that happen.
---- The irony is so thick you can cut it with a knife. Those of us who were whitebox users surely remember how the updates came slower and slower and our sense of frustration of never knowing how/if/when the updates would come. Your reminder (because I had forgotten) that they used timeliness as the main selling point for switching to CentOS well... if that isn't a wake up call to Johnny & Karanbir, then nothing will do it.
At least John Morris never made any pretense of whitebox being a community project nor did he promise updates to be anything except on his own timetable. I remember how awkward I felt when Johnny would use the WBEL mail list to suggest to people to switch to CentOS and laughed the other day when he was rather perturbed because the CentOS list was used to promote the idea of switching to SL. More irony.
I resolved to not install WBEL 4.0 on any system because I couldn't trust it to be timely and now, here we are at 6.0 and I feel the same way about CentOS. Full circle.
The sycophants on this list probably don't recognize just how valuable the 'dag' repo (aka rpmforge) has been to the RHEL/CentOS/SL/etc. ecosystem but my feeling is that if Dag can't hold the CentOS dev's feet to the fire, then no one can. Evidently I am one of the "ungrateful bastards" http://lists.centos.org/pipermail/centos/2011-May/111670.html but you could never be considered to be one of them.
Craig
Dag wrote:
Before I leave this list let me take you back about 7 years to the Whitebox mailinglist. You may not remember that Whitebox had a list of issues of its own, no timely updates, no community effort, lack of good communication. It was mostly a one-man-effort.
bummer to see you go Dag...
yet as you know, everything has issues...
if one mainly looks for "or" at things in a negative perspective, you will always find more of same...
yet believe it or not, if you look for the good, and count your blessings based on it, the count of such will never end...
some are ungrateful, yes... but for the most part they are sinfully ignorant & think way too highly of themselves
what is truly, seriously ironic is that the ignorant / ungrateful crowd gets a chance to come out of the woodwork... you know the ones... they havent done whatever is necessary to (in major way) help centos as a whole and/or do any core centos work during CentOSs' lifetime (7 years ???) while the core centos heros carry the majority of the load the whole time.
then when the proverbial doody hits the fan and the centos heros (as always) roll up sleeves & multiple distro works are progressing at a variable rate
the ignorant act like they have all the answers and can help the centos heros, YET the ignorant never actually roll up their sleves and do anything to help.
mainly lots of crying and peeping like helpless baby birds waiting for food.
i may not be 100% correct, yet one thing i have picked up on over the years in relationship to volunteering for CentOS is that the centos heros do not have time to BABY and SPOON FEED new recruits.
- rh
On 05/12/2011 10:09 AM, Craig White wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
OH, and most people take off Thanksgiving, Christmas, and New Year's day vacations, so the release of 5.6 and 6.0 are very close when you take into account that usually most people take off 2-4 weeks of the time between Mid November and the first week in January.
On Thu, May 12, 2011 at 10:09 AM, Craig White craig.white@ttiltd.com wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
Same "time frame," if you want to be technical. As we've seen, work started on CentOS 6 and was suspended while the developers worked on 4.9 and 5.6. So, during the same time "frame," two point releases and a major release all needed to be done. Sorry I didn't carefully choose my words or go into "lawyer speak" mode.
And, has been noted, Scientific Linux gave preference to 6.0 and, as of yet, still have not completed 5.6. It's not often that either development team gets hit with a "triple whammy" like this. Scientific Linux chose one path, CentOS chose another. Personally I happen to agree with CentOS' choice here.
On Thu, May 12, 2011 at 5:31 PM, aurfalien@gmail.com wrote:
On May 12, 2011, at 4:47 PM, Ron Blizzard wrote:
CentOS chose another. Personally I happen to agree with CentOS' choice here.
+1
I think *both* distros made the right choice. :)
CentOS and SL handle security updates differently. CentOS's choice was right for CentOS because the delivery of security updates provided by 5.6 was more urgent for existing 5.x users than getting a "non-existing" new major release out.
SL's choice was right for SL because they backport security updates. This is similar to what upstream's EUS (Extended Update Support) provides -- one can stay at a point release (like 5.4) for a period of time security fixes are available. So doing 6.0 first is not a concern for 5.x users.
Akemi
On May 12, 2011, at 4:47 PM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 10:09 AM, Craig White craig.white@ttiltd.com wrote:
On May 12, 2011, at 2:05 AM, Ron Blizzard wrote:
On Thu, May 12, 2011 at 1:08 AM, Mark Bradbury mark.bradbury@gmail.com wrote:
Do you expect the C6.0 -> C6.1 differences to be more complex, or less complex than the C5.5 -> C5.6 differences ?
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
Get over yourself Dag ... for goodness sake.
Why? seems like a valid point to me.
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
I think you are confusing overlap with simultaneous.
• 2011-02-16: Distribution Release: Red Hat Enterprise Linux 4.9 • 2011-01-13: Distribution Release: Red Hat Enterprise Linux 5.6 • 2010-11-10: Distribution Release: Red Hat Enterprise Linux 6
2 months elapsed from release of 6.0 before 5.6 and more than another month before 4.9
Hardly qualifies at the same time unless you consider 3 months to be essentially the same time.
Same "time frame," if you want to be technical. As we've seen, work started on CentOS 6 and was suspended while the developers worked on 4.9 and 5.6. So, during the same time "frame," two point releases and a major release all needed to be done. Sorry I didn't carefully choose my words or go into "lawyer speak" mode.
---- 6 months? Beta for 6.1 already is out? Do you actually think carefully chosen words or the notion of interim point releases is really meaningful to people who have been waiting for 6? ----
And, has been noted, Scientific Linux gave preference to 6.0 and, as of yet, still have not completed 5.6. It's not often that either development team gets hit with a "triple whammy" like this. Scientific Linux chose one path, CentOS chose another. Personally I happen to agree with CentOS' choice here.
---- CentOS has always been a take it or leave it proposition and thus nothing has really changed except that many businesses have become reliant upon it and I see my company and many other companies turning to Ubuntu not just because of the slow turnaround by CentOS but upstream's long window between releases. Surely anyone who is supporting Ruby on Rails (or PHP prior to the PHP 5.3 update in the 5.6 update) understands the issue.
Lastly, Johnny has made clear that this is not supposed to be an SL discussion list but curiously enough, SL is invoked by those who want to use SL to justify the alacrity of the CentOS 6.0 release. As was pointed out, though their 5.6 update was slow or apparently still not out, the updates all came out long ago so what you are actually referring to was the set of installation discs that are only really needed by people who want to install on newly supported hardware.
Craig
On Fri, May 13, 2011 at 12:30 PM, Craig White craig.white@ttiltd.com wrote:
Lastly, Johnny has made clear that this is not supposed to be an SL discussion list but curiously enough, SL is invoked by those who want to use SL to justify the alacrity of the CentOS 6.0 release. As was pointed out, though their 5.6 update was slow or apparently still not out, the updates all came out long ago so what you are actually referring to was the set of installation discs that are only really needed by people who want to install on newly supported hardware. <<
Give me a break. Comparing SL and CentOS release dates is not the same as saying "I've moved to SL, but I'm still going to come to the CentOS mailing list and bitch about it for the rest of my life." My point is that both CentOS and SL had to deal with two point releases and a major release all at the same time... err... in the same "time frame." They each chose to handle the situation differently, and it appears that both will *finish* their three releases at approximately the same time. This is an exceptional case, it doesn't happen very often. By it's very nature a rebuild's distribution release *must* be delayed from its upstream release. Most CentOS users understand and accept this. So, if you *must* have the newest, cutting edge, release *immediately* you're going to need to license the upstream product. If you want to call that a "take it or leave it" proposition, then use that phrase. Personally I see it as simply bowing to the dictates of reality.
On Saturday, May 14, 2011 01:30 AM, Craig White wrote:
CentOS has always been a take it or leave it proposition and thus nothing has really changed except that many businesses have become reliant upon it and I see my company and many other companies turning to Ubuntu not just because of the slow turnaround by CentOS but upstream's long window between releases. Surely anyone who is supporting Ruby on Rails (or PHP prior to the PHP 5.3 update in the 5.6 update) understands the issue.
You want to go Ubuntu 'LTS'? Be my guest. Yeah, they have a lot more packages by default but don't expect any backports or what not for their crap.
On Fri, May 13, 2011 at 8:50 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
On Saturday, May 14, 2011 01:30 AM, Craig White wrote:
CentOS has always been a take it or leave it proposition and thus nothing has really changed except that many businesses have become reliant upon it and I see my company and many other companies turning to Ubuntu not just because of the slow turnaround by CentOS but upstream's long window between releases. Surely anyone who is supporting Ruby on Rails (or PHP prior to the PHP 5.3 update in the 5.6 update) understands the issue.
You want to go Ubuntu 'LTS'? Be my guest. Yeah, they have a lot more packages by default but don't expect any backports or what not for their crap.
There are advantages and disadvantages to installing the latest Ubuntu (or Fedora) on the desktop rather than CentOS, but Ubuntu's not crap on the server-side. You have an X-less Debian testing install with plymouth and upstart; "testing" might not inspire you with confidence but it's proven to be very stable up to now. They freeze Debian imports four months before release so they have enough time to stabilize the release.
Ubuntu does have backports (I've never used them though). For example, for the current LTS: http://packages.ubuntu.com/lucid-backports/
My clients who switch from CentOS (I was supporting almost 100% CentOS a few years ago but the Debian and Ubuntu share - especially Ubuntu - is growing quickly) do so because it's "in vogue" (my interpretation) and because the packages are more recent than CentOS's. They often don't even care about LTS!
Tom H wrote:
On Fri, May 13, 2011 at 8:50 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
On Saturday, May 14, 2011 01:30 AM, Craig White wrote:
CentOS has always been a take it or leave it proposition and thus nothing has really changed except that many businesses have become reliant upon it and I see my company and many other companies turning to Ubuntu not just because of the slow turnaround by CentOS but upstream's long window between releases. Surely anyone who is supporting Ruby on Rails (or PHP prior to the PHP 5.3 update in the 5.6 update) understands the issue.
You want to go Ubuntu 'LTS'? Be my guest. Yeah, they have a lot more packages by default but don't expect any backports or what not for their crap.
There are advantages and disadvantages to installing the latest Ubuntu (or Fedora) on the desktop rather than CentOS, but Ubuntu's not crap on the server-side. You have an X-less Debian testing install with plymouth and upstart; "testing" might not inspire you with confidence but it's proven to be very stable up to now. They freeze Debian imports four months before release so they have enough time to stabilize the release.
Ubuntu does have backports (I've never used them though). For example, for the current LTS: http://packages.ubuntu.com/lucid-backports/
My clients who switch from CentOS (I was supporting almost 100% CentOS a few years ago but the Debian and Ubuntu share - especially Ubuntu - is growing quickly) do so because it's "in vogue" (my interpretation) and because the packages are more recent than CentOS's. They often don't even care about LTS! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Most of us use CentOS/RHEL for servers BECAUSE it is not updated constanly with new versions. Having bunch of noobs (server owners and admins with Windows desktops) liking something doesn't make them right or smart, just fashionable. Can you take this off-list? I am REALLY tired of reading non-CentOS stuff.
Can you take this off-list? I am REALLY tired of reading non-CentOS stuff.
Please keep it here. CentOS vs SL and CentOS vs Ubuntu are as on-topic as anything else. Since TUV stopped supporting my non-PAE processors, I am obliged to find a new home. Ubuntu is one of the options.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. Life is not measured by the number of breaths we take, but by the moments that take our breath away.
//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 Monday, May 16, 2011 09:11 PM, Brunner, Brian T. wrote:
Can you take this off-list? I am REALLY tired of reading non-CentOS stuff.
Please keep it here. CentOS vs SL and CentOS vs Ubuntu are as on-topic as anything else. Since TUV stopped supporting my non-PAE processors, I am obliged to find a new home. Ubuntu is one of the options.
So long as it is legitimate dev/whatever bashing. So, shall I start with the 'LTS' 'maintenance', or the launchpad bug devs and chums system, or the Ubuntu community and 'community' aka Developers or the lists/irc/forums?
Ubuntu is however convenient as a desktop if you have Nvidia graphics but not everything on the desktop is going to be peachy. But for anything else...I dunno. I have this Ubuntu Hardy server but I sure don't like the fact that I have to program me own firewall rule scripts. And no, don't give me firestarter or ufw. If only I had a Centos disk when I had to build that server...
On 05/12/2011 02:05 AM, Ron Blizzard wrote:
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
As far as users know, all work on 6.0 was postponed to get 5.6 done. At the time of 5.6's release, it was the only release the team was working on. Work on 5 should have been something the team was quite familiar with by that time. If 5.6 took 3 months to finish, then Dag's question is quite fair: why would we expect 6.1 to take so much less time?
On Sun, May 15, 2011 at 3:11 AM, Gordon Messmer yinyang@eburg.com wrote:
On 05/12/2011 02:05 AM, Ron Blizzard wrote:
But at that time there should only be one point release on the table, instead of two point releases and one major release. Is everyone forgetting that 4.9, 5.6 and 6.0 were all out at the same time?
As far as users know, all work on 6.0 was postponed to get 5.6 done. At the time of 5.6's release, it was the only release the team was working on. Work on 5 should have been something the team was quite familiar with by that time. If 5.6 took 3 months to finish, then Dag's question is quite fair: why would we expect 6.1 to take so much less time?
You're leaving out release 4.9. You're also leaving out the fact that two major holidays occurred during the time *frame* that these three releases needed to be built. You're also leaving out the fact (as mentioned by one of the developers) that they had to start from scratch on 6.0 -- that they'll be "set up" for 6.1 when it comes out. You're also leaving out the fact that SL had to rebuild the same three releases -- and they're still working on the last of those -- so the amount of time it's taking CentOS developers squares with the amount of time required by the SL developers.
Check out the history of point releases between SL and CentOS. If I remember correctly the release dates are pretty close -- I think CentOS is usually out slightly earlier then SL,(realizing, of course, that the two distributions are handled differently).
A quick review. 6.0 -- CentOS - (Soon) SL - 3/3/11 <-- same time frame (1 of 3) 5.6 -- CentOS - 4/8/11 SL - (Soon) <-- same time frame (1 of 3) 5.5 -- CentOS - 5/14/10 SL - 5/19/10 5.4 -- CentOS - 10/21/9 SL - 11/4/9 5.3 -- CentOS - 3/31/9 SL - 3/19/9 5.2 -- CentOS - 6/24/8 SL - 6/26/8 5.1 -- CentOS - 12/2/7 SL - 1/16/8 5.0 -- CentOS - 4/12/7 SL - 5/4/7 4.9 -- CentOS - 3/2/11 SL - 5/6/11 <-- same time frame (1 of 3) 4.8 -- CentOS - 8/21/9 SL - 7/28/9 4.7 -- CentOS - 9/13/8 SL - 9/3/8 4.6 -- CentOS - 12/16/7 SL - 3/12/8
You can look them up on Wikipedia if you want more. Do you see any huge change in patterns here? I don't. Note the first of CentOS' releases on these three updates came out on 3/2/11, SL's first release came on 3/3/11. It appears that the last of the three releases (one for each distribution) will happen at about the same time also (I don't know how long it takes a CentOS release to get through QA or how long it takes SL to go from beta to finished, but they're both on the home stretch.)
So, overall, it's taking both distributions a little less than seven months on these two point releases and one major release. If you're "cynical" you could say it's taken CentOS almost seven months on 6.0, where it took SL a bit less than four months. But, if I were cynical, I could say, yeah, but it only took CentOS about three weeks on 4.9 and it took SL nearly three months. And CentOS got 5.6 out in three months where it's taking SL nearly five months. (I realize this doesn't tell the whole story but I'm trying to drive home the point that there are three releases and both rebuild distributions developers are taking about the same amount of time. It is the priorities that are different.) I don't see the need for constant harping.
(Sorry to ramble.)
A perhaps stupid question from a newby
Why 4.9 is out in a so long time frame after 5.0?
5.6 -- CentOS - 4/8/11 SL - (Soon) <-- same time frame (1 of 3) 5.5 -- CentOS - 5/14/10 SL - 5/19/10 5.4 -- CentOS - 10/21/9 SL - 11/4/9 5.3 -- CentOS - 3/31/9 SL - 3/19/9 5.2 -- CentOS - 6/24/8 SL - 6/26/8 5.1 -- CentOS - 12/2/7 SL - 1/16/8 5.0 -- CentOS - 4/12/7 SL - 5/4/7 4.9 -- CentOS - 3/2/11 SL - 5/6/11 <-- --- Michel Donais
On Sun, May 15, 2011 at 16:35, Michel Donais donais@telupton.com wrote:
A perhaps stupid question from a newby
Why 4.9 is out in a so long time frame after 5.0?
5.6 -- CentOS - 4/8/11 SL - (Soon) <-- same time frame (1 of 3) 5.5 -- CentOS - 5/14/10 SL - 5/19/10 5.4 -- CentOS - 10/21/9 SL - 11/4/9 5.3 -- CentOS - 3/31/9 SL - 3/19/9 5.2 -- CentOS - 6/24/8 SL - 6/26/8 5.1 -- CentOS - 12/2/7 SL - 1/16/8 5.0 -- CentOS - 4/12/7 SL - 5/4/7 4.9 -- CentOS - 3/2/11 SL - 5/6/11 <--
It's a different branch. The 4.x branch had/has continued support even though the 5.x (and now 6.x) branches are released.
On 05/15/2011 08:41 AM, Dotan Cohen wrote:
On Sun, May 15, 2011 at 16:35, Michel Donais donais@telupton.com wrote:
A perhaps stupid question from a newby
Why 4.9 is out in a so long time frame after 5.0?
5.6 -- CentOS - 4/8/11 SL - (Soon) <--same time frame (1 of 3) 5.5 -- CentOS - 5/14/10 SL - 5/19/10 5.4 -- CentOS - 10/21/9 SL - 11/4/9 5.3 -- CentOS - 3/31/9 SL - 3/19/9 5.2 -- CentOS - 6/24/8 SL - 6/26/8 5.1 -- CentOS - 12/2/7 SL - 1/16/8 5.0 -- CentOS - 4/12/7 SL - 5/4/7 4.9 -- CentOS - 3/2/11 SL - 5/6/11 <--
It's a different branch. The 4.x branch had/has continued support even though the 5.x (and now 6.x) branches are released.
Every branch of Enterprise Linux is supported with updated for 7 years ... that is the purpose of Enterprise Linux. This is as compared to the standard Linux distributions that usually have 1 year (current and last version ... release every 6 months).
More info here for the upstream ... CentOS mirrors all but the "Extended Life Cycle":
https://access.redhat.com/support/policy/updates/errata/
(CentOS would also mirror the Extended Life Cycle, but we can not get the SRPMS from the upstream provider)
On 05/15/2011 03:52 AM, Ron Blizzard wrote:
On Sun, May 15, 2011 at 3:11 AM, Gordon Messmeryinyang@eburg.com wrote:
As far as users know, all work on 6.0 was postponed to get 5.6 done. At the time of 5.6's release, it was the only release the team was working on. Work on 5 should have been something the team was quite familiar with by that time. If 5.6 took 3 months to finish, then Dag's question is quite fair: why would we expect 6.1 to take so much less time?
You're leaving out release 4.9.
No, I'm not. 4.9 was released just over a month after 5.6. If 5.6 couldn't be finished in that month, why would 6.1 be finished in only a month?
You're also leaving out the fact that two major holidays occurred during the time *frame* that these three releases needed to be built.
I'm not sure which two you're referring to. Are there going to be no holidays following the release of 6.1?
You're also leaving out the fact (as mentioned by one of the developers) that they had to start from scratch on 6.0 -- that they'll be "set up" for 6.1 when it comes out.
I don't see how that's relevant. They didn't have to start from scratch on 5.6, and that took three months. Why would 6.1 take so much less time than 5.6?
You're also leaving out the fact that SL had to rebuild the same three releases -- and they're still working on the last of those -- so the amount of time it's taking CentOS developers squares with the amount of time required by the SL developers.
No, I'm not. Neither I nor Dag, as far as I saw, brought SL into the conversation at all. The question is not whether CentOS can build releases in less time than SL, or even a reasonable amount of time. The question that Dag posed was why users (or the release team) should expect 6.1 to be done in one month, when 5.6 took three and was a fairly well rehearsed process by that point.
On Sun, May 15, 2011 at 3:00 PM, Gordon Messmer yinyang@eburg.com wrote:
No, I'm not. Neither I nor Dag, as far as I saw, brought SL into the conversation at all. The question is not whether CentOS can build releases in less time than SL, or even a reasonable amount of time. The question that Dag posed was why users (or the release team) should expect 6.1 to be done in one month, when 5.6 took three and was a fairly well rehearsed process by that point.
Obviously I missed the part where I (or someone) said (or claimed) that 6.1 could be done in a month. What does a month have to do with anything?
There is a certain amount of time required to rebuild the "upstream" releases. Whatever that amount of time is, CentOS and SL seem to require about the same number. So I'm trying to figure out... why is CentOS attacked so much for taking too long? -- whereas SL is lauded as the "go to" distribution?
As I showed in the list of release dates, CentOS and SL have almost always been fairly close (CentOS usually a little quicker). So why the claim that CentOS is getting worse on release dates? (General claim, not specifically yours.) I see no pattern in the release dates to indicate CentOS is generally falling behind SL. As has mentioned too many times now, CentOS is slower getting 6.0 out because they chose to update 4.x and 5.x first. But the time to get all three releases released appears to almost the same for both distributions.
And the reason I bring this up is 1) SL is mentioned in the subject line and 2) SL is (I believe) the only other major community Red Hat rebuilding project. So, who else should I be comparing CentOS release dates with?
On 05/15/2011 02:23 PM, Ron Blizzard wrote:
Obviously I missed the part where I (or someone) said (or claimed) that 6.1 could be done in a month.
Well, that is where this branch of the thread began.
http://lists.centos.org/pipermail/centos/2011-May/111443.html
Ljubomir Ljubojevic began the branch with the expectation that there would be not more than a month between C6.0 and C6.1. I believe that he misspoke, and probably meant that there would be not more than one month between the upstream release of RHEL 6.1 and the release of C6.1.
http://lists.centos.org/pipermail/centos/2011-May/111473.html
Dag Wieers replied and asked if there was any reason to believe that this would actually happen. I think this is a perfectly valid question. If 5.6 could not be done in a month, why would we expect that 6.1 would be?
What does a month have to do with anything?
It was a time frame posed on the list. I don't believe it has any significance beyond Ljubomir's suggestion that 6.1 could be completed in that amount of time. It seems unlikely.
There is a certain amount of time required to rebuild the "upstream" releases. Whatever that amount of time is, CentOS and SL seem to require about the same number. So I'm trying to figure out... why is CentOS attacked so much for taking too long? -- whereas SL is lauded as the "go to" distribution?
Well, CentOS is generally attacked for taking a long time because users have had no visibility into the process. Most people make what I would think is a perfectly reasonable request: not that the distribution is available immediately and not that a specific release date is given and kept, but that information about the tasks to be completed is published. The process around building CentOS has traditionally been very secretive, which makes the name "*Community* Enterprise OS" seem very inapt.
SL is not so much lauded, I think, as discussed right now because users who want a rebuild of RHEL 6.0 have no other option. There is no beta of CentOS for them to install and review (which would make contribution significantly easier). Users are trying to figure out whether or not it makes sense for them to wait for CentOS 6.0 or use something that's available now. Because they have very little insight into the process or progress that has been made, they cannot easily evaluate that question. It is reasonable for this to produce a great deal of anxiety.
As I showed in the list of release dates, CentOS and SL have almost always been fairly close (CentOS usually a little quicker). So why the claim that CentOS is getting worse on release dates? (General claim, not specifically yours.)
Look at wikipedia's page describing CentOS. They include a column for the delay between the upstream release and CentOS's. For the 5 series, it looks like:
Release Delay 5 28d 5.1 25d 5.2 34d 5.3 69d 5.4 49d 5.5 44d 5.6 85d
Almost every release in the 5 series took longer than the initial release for 5.0. Even if you ignore the release of 5.6, there is a generally upward trend in the amount of time taken for each release. How could anyone reasonably claim that CentOS is NOT getting worse on release dates?
I can't even begin to comprehend the logical failure behind the idea that because SL and CentOS are keeping up with each other that CentOS is not getting worse. Again, Dag interjected only to ask why any reasonable person would expect 6.1 to take only one month when 5.6 took three. The fact that there is a general trend toward longer release delays supports that question.
I see no pattern in the release dates to indicate CentOS is generally falling behind SL.
That's fine, but that's not what's being discussed.
On 05/15/2011 05:12 PM, Gordon Messmer wrote:
On 05/15/2011 02:23 PM, Ron Blizzard wrote:
Obviously I missed the part where I (or someone) said (or claimed) that 6.1 could be done in a month.
Well, that is where this branch of the thread began.
http://lists.centos.org/pipermail/centos/2011-May/111443.html
Ljubomir Ljubojevic began the branch with the expectation that there would be not more than a month between C6.0 and C6.1. I believe that he misspoke, and probably meant that there would be not more than one month between the upstream release of RHEL 6.1 and the release of C6.1.
http://lists.centos.org/pipermail/centos/2011-May/111473.html
Dag Wieers replied and asked if there was any reason to believe that this would actually happen. I think this is a perfectly valid question. If 5.6 could not be done in a month, why would we expect that 6.1 would be?
What does a month have to do with anything?
It was a time frame posed on the list. I don't believe it has any significance beyond Ljubomir's suggestion that 6.1 could be completed in that amount of time. It seems unlikely.
There is a certain amount of time required to rebuild the "upstream" releases. Whatever that amount of time is, CentOS and SL seem to require about the same number. So I'm trying to figure out... why is CentOS attacked so much for taking too long? -- whereas SL is lauded as the "go to" distribution?
Well, CentOS is generally attacked for taking a long time because users have had no visibility into the process. Most people make what I would think is a perfectly reasonable request: not that the distribution is available immediately and not that a specific release date is given and kept, but that information about the tasks to be completed is published. The process around building CentOS has traditionally been very secretive, which makes the name "*Community* Enterprise OS" seem very inapt.
SL is not so much lauded, I think, as discussed right now because users who want a rebuild of RHEL 6.0 have no other option. There is no beta of CentOS for them to install and review (which would make contribution significantly easier). Users are trying to figure out whether or not it makes sense for them to wait for CentOS 6.0 or use something that's available now. Because they have very little insight into the process or progress that has been made, they cannot easily evaluate that question. It is reasonable for this to produce a great deal of anxiety.
As I showed in the list of release dates, CentOS and SL have almost always been fairly close (CentOS usually a little quicker). So why the claim that CentOS is getting worse on release dates? (General claim, not specifically yours.)
Look at wikipedia's page describing CentOS. They include a column for the delay between the upstream release and CentOS's. For the 5 series, it looks like:
Release Delay 5 28d 5.1 25d 5.2 34d 5.3 69d 5.4 49d 5.5 44d 5.6 85d
Almost every release in the 5 series took longer than the initial release for 5.0. Even if you ignore the release of 5.6, there is a generally upward trend in the amount of time taken for each release. How could anyone reasonably claim that CentOS is NOT getting worse on release dates?
I can't even begin to comprehend the logical failure behind the idea that because SL and CentOS are keeping up with each other that CentOS is not getting worse. Again, Dag interjected only to ask why any reasonable person would expect 6.1 to take only one month when 5.6 took three. The fact that there is a general trend toward longer release delays supports that question.
I see no pattern in the release dates to indicate CentOS is generally falling behind SL.
Where is Ubuntu telling people exactly where they stand on producing a their new releases.
What about Red Hat ... how about Fedora.
Is there someplace I do not know about where these distributions tell you what they are having trouble building?
Show me another list where the developers interact with the users as much as this one.
CentOS has never been secretive. We published examples of our build scripts for the RPMs and the disros, the mock we use and plague. Something Red Hat has never done.
We have never been secretive. I even posted the hidden build requirements.
What the hell is secretive about the process ... I have had it with this list.
Screw it ... I quit.
Where is the SELS
On 05/15/2011 06:10 PM, Johnny Hughes wrote:
Where is Ubuntu telling people exactly where they stand on producing a their new releases.
What about Red Hat ... how about Fedora.
I don't know about Ubuntu, I don't use it.
Fedora, on the other hand publishes their schedule: http://fedoraproject.org/wiki/Releases/15/Schedule And the release life cycle: http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle And their release criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria And release engineering documentation, including the names of responsible persons and directions for getting involved: http://fedoraproject.org/wiki/ReleaseEngineering And standard operating procedures: http://fedoraproject.org/wiki/ReleaseEngineering/SOP
The release criteria includes a Bugzilla list for a release blocker bug which shows users what issues currently need to be resolved before the release. Users are very well informed about the state of the project.
Fedora uses Koji to build packages. Users can view build logs in the Koji interface as well.
After building packages, maintainers push to Bodhi, where users can test the package and indicate success or failure before the package is finally published.
If CentOS were run even remotely like Fedora, these discussions wouldn't come up.
Is there someplace I do not know about where these distributions tell you what they are having trouble building?
Apparently.
Show me another list where the developers interact with the users as much as this one.
My interactions with Fedora's developers and maintainers have always been both pleasant and productive.
CentOS has never been secretive. We published examples of our build scripts for the RPMs and the disros, the mock we use and plague. Something Red Hat has never done.
It doesn't always seem that way to users. Certainly, the trend has been to greater openness and more insight. That has been encouraging.
In February of '09, Karanbir published a blog on the r-v-m routine. I vaguely recall that sometime in the years before that he stated that the scripts used to build the release would not be released, which was a significant part of the reason that I, personally, have regarded the project as somewhat secretive. More generally, I would describe the project as somewhat secretive by virtue of the lack of communication with users. I don't intend to imply that the developers are malicious, just that many users clearly feel like they do not and cannot understand the state of the project.
Look, I appreciate the new QA site. It's great. I sort of remember someone linking to a page with a list of the tasks blocking the release of C6, even though I can't find it now. That also makes me a happier user. However, I can appreciate CentOS and the work of its developers without thinking that it is perfect, right? Is that too much to ask?
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
Wow. I guess not.
All of that is more or less a distraction from the point at which this branch of the thread began. One person suggested that 6.1 might take only a month, and that seems highly questionable. Without making any value judgments about whether or not the distribution *should* be available in one month, or whether some other project can do it faster, and without questioning the competence of anyone, I still think it's legitimate to express doubts that a release can be made ready in that time frame. There is no recent evidence that users can expect that.
Gordon Messmer wrote:
On 05/15/2011 06:10 PM, Johnny Hughes wrote:
Where is Ubuntu telling people exactly where they stand on producing a their new releases.
What about Red Hat ... how about Fedora.
I don't know about Ubuntu, I don't use it.
Fedora, on the other hand publishes their schedule: http://fedoraproject.org/wiki/Releases/15/Schedule And the release life cycle: http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle And their release criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria And release engineering documentation, including the names of responsible persons and directions for getting involved: http://fedoraproject.org/wiki/ReleaseEngineering And standard operating procedures: http://fedoraproject.org/wiki/ReleaseEngineering/SOP
The release criteria includes a Bugzilla list for a release blocker bug which shows users what issues currently need to be resolved before the release. Users are very well informed about the state of the project.
Fedora uses Koji to build packages. Users can view build logs in the Koji interface as well.
After building packages, maintainers push to Bodhi, where users can test the package and indicate success or failure before the package is finally published.
If CentOS were run even remotely like Fedora, these discussions wouldn't come up.
There is no way that CentOS or any other REBUILD project can be run as DEVELOPMENT project where you can build as you like. Scan both mailing lists few months back where those differences were thoroughly explained.
<snip>
All of that is more or less a distraction from the point at which this branch of the thread began. One person suggested that 6.1 might take only a month, and that seems highly questionable. Without making any value judgments about whether or not the distribution *should* be available in one month, or whether some other project can do it faster, and without questioning the competence of anyone, I still think it's legitimate to express doubts that a release can be made ready in that time frame. There is no recent evidence that users can expect that.
It started much earlier then my post about "around 1 month" timeframe, I would say a week or so at least in this thread allone. Real start of discussion started several months ago. If you are brave enough, read entire mail lists (both of them) and keep track of who said what, when and as a response to what. Then you will have slightly different perspective.
Ljubomir
On Mon, May 16, 2011 at 7:45 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
Gordon Messmer wrote:
On 05/15/2011 06:10 PM, Johnny Hughes wrote:
Where is Ubuntu telling people exactly where they stand on producing a their new releases.
What about Red Hat ... how about Fedora.
I don't know about Ubuntu, I don't use it.
Fedora, on the other hand publishes their schedule: http://fedoraproject.org/wiki/Releases/15/Schedule And the release life cycle: http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle And their release criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria And release engineering documentation, including the names of responsible persons and directions for getting involved: http://fedoraproject.org/wiki/ReleaseEngineering And standard operating procedures: http://fedoraproject.org/wiki/ReleaseEngineering/SOP
The release criteria includes a Bugzilla list for a release blocker bug which shows users what issues currently need to be resolved before the release. Users are very well informed about the state of the project.
Fedora uses Koji to build packages. Users can view build logs in the Koji interface as well.
After building packages, maintainers push to Bodhi, where users can test the package and indicate success or failure before the package is finally published.
If CentOS were run even remotely like Fedora, these discussions wouldn't come up.
There is no way that CentOS or any other REBUILD project can be run as DEVELOPMENT project where you can build as you like. Scan both mailing lists few months back where those differences were thoroughly explained.
Look at the above. It was Johnny H who brought up the other distributions when he should've only chosen to compare CentOS to SL, by your standards. Whatever their reasons, the CentOS developers don't want to publish that information. Users can ask (as many have) but it's the decision of the developers and that's it. Bringing it up day after day isn't particularly productive but those who do so are free to do so - and their motives shouldn't be assumed to be negative. For those who'd like to see that policy change, bringing it up from time to time (once a year for example) might be worthwhile.
Tom H wrote:
On Mon, May 16, 2011 at 7:45 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
Gordon Messmer wrote:
On 05/15/2011 06:10 PM, Johnny Hughes wrote:
Where is Ubuntu telling people exactly where they stand on producing a their new releases.
What about Red Hat ... how about Fedora.
I don't know about Ubuntu, I don't use it.
Fedora, on the other hand publishes their schedule: http://fedoraproject.org/wiki/Releases/15/Schedule And the release life cycle: http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle And their release criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria And release engineering documentation, including the names of responsible persons and directions for getting involved: http://fedoraproject.org/wiki/ReleaseEngineering And standard operating procedures: http://fedoraproject.org/wiki/ReleaseEngineering/SOP
The release criteria includes a Bugzilla list for a release blocker bug which shows users what issues currently need to be resolved before the release. Users are very well informed about the state of the project.
Fedora uses Koji to build packages. Users can view build logs in the Koji interface as well.
After building packages, maintainers push to Bodhi, where users can test the package and indicate success or failure before the package is finally published.
If CentOS were run even remotely like Fedora, these discussions wouldn't come up.
There is no way that CentOS or any other REBUILD project can be run as DEVELOPMENT project where you can build as you like. Scan both mailing lists few months back where those differences were thoroughly explained.
Look at the above. It was Johnny H who brought up the other distributions when he should've only chosen to compare CentOS to SL, by your standards. Whatever their reasons, the CentOS developers don't want to publish that information. Users can ask (as many have) but it's the decision of the developers and that's it. Bringing it up day after day isn't particularly productive but those who do so are free to do so - and their motives shouldn't be assumed to be negative. For those who'd like to see that policy change, bringing it up from time to time (once a year for example) might be worthwhile.
Tom, you are way off the point I was making. RHEL, Fedora, Debian, Ubuntu, all other distro's are *developed* and can change at any time. You can track changes, contribute patches and track progress (if you have access). Anything you build at any point of time is exactly what you want. How ever you compile it, what you wanted is what you got.
CentOS is *recreating* RHEL, and must/wants to make it *exactly* like RHEL is, as much as possible. There is no development (for 90-95% of the packages) to patch contributions, no "we are changing our build environment for this release because this one is better". You are reverse engineering complete product. All of this was, at length, discussed on this or devel list, look it up if you can not wrap your head around this concept/problem.
Ljubomir
On 5/18/11 5:05 AM, Ljubomir Ljubojevic wrote:
Tom, you are way off the point I was making. RHEL, Fedora, Debian, Ubuntu, all other distro's are *developed* and can change at any time. You can track changes, contribute patches and track progress (if you have access). Anything you build at any point of time is exactly what you want. How ever you compile it, what you wanted is what you got.
There are closed software/OS development processes too. If your mindset is that closed is better, why are you even interested in Linux where most wouldn't exist and certainly not be as nice if it weren't open and had attracted otherwise unpredictable support and input.
CentOS is *recreating* RHEL, and must/wants to make it *exactly* like RHEL is, as much as possible. There is no development (for 90-95% of the packages) to patch contributions, no "we are changing our build environment for this release because this one is better".
It was discussed, but that doesn't change anyone's mindset about open vs. closed processes or whether being more open and permitting community insight and participation would ultimately keep the project from going the way of Whitebox. Yet another public posting on the topic linked from http://distrowatch.com/weekly.php?issue=20110516#news http://blog.2ndquadrant.com/en/2011/05/the-rise-and-fall-of-centos.html
You are reverse engineering complete product. All of this was, at length, discussed on this or devel list, look it up if you can not wrap your head around this concept/problem.
There's also a reasonable question about whether this process could be better automated, in which case it becomes typical software development for programs that solve the dependencies and find and assemble the requirements.
There's also a reasonable question about whether this process could be better automated,
How do you *automate* a system where the fundamental rules change 'without notice to users'?
in which case it becomes typical software development for programs that solve the dependencies and find and assemble the requirements.
Rebuilding somebody else's sources without their build environment isn't typical. It's MindReading 101.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. Life is not measured by the number of breaths we take, but by the moments that take our breath away.
//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 Wednesday, May 18, 2011 09:23:14 AM Brunner, Brian T. wrote:
Rebuilding somebody else's sources without their build environment isn't typical. It's MindReading 101.
It's worse than that in the specific case of EL6. It's replicating the result without replicating the build system. It's a pretty well-known thing that upstream is building with Koji fed from a source code management system; CentOS is not as far as we know (and it's overkill anyway, unless you add several things to the distribution as SL does, and they're using Koji for SL6, and started learning Koji and setting up their buildsystem for 6 nearly a year ago). Koji in fact will not allow, by default, a 'normal' user to rebuild from source RPM, but requires building out of the SCM for normal users. The case of a 'from source RPM' rebuild is not Koji's forte.
It's also fairly well-known that mock builds in koji and mock builds outside of koji can sometimes differ. Grep the archives of several lists to verify that; I've seen it before, but I don't have time at the moment to pull up the reference. I have a VAX to redisk and boot up....
On 5/18/2011 8:23 AM, Brunner, Brian T. wrote:
There's also a reasonable question about whether this process could be better automated,
How do you *automate* a system where the fundamental rules change 'without notice to users'?
You have the results you want to reproduce. You have a list of likely suspects for the components involved (some of which may be the same as your binary results). You have a way to test if your output is a reasonable match. The part in between can either be brute force trial and error, predictions based on hints from file or source change timestamps on the components and target outputs, looking at the library linkages you want to reproduce, or some combination thereof. The 'list of likely suspects' and where to find them might be hard to automate but it's something that might benefit from more eyes.
in which case it becomes typical software development for programs that solve the dependencies and find and assemble the requirements.
Rebuilding somebody else's sources without their build environment isn't typical. It's MindReading 101.
Whether a computer program can simulate mindreading better than a person (reading someone else's mind)is still up in the air. My money would be on the computer going forward anyway, especially if speed is one of the ways you judge the results. Whether exposing the process to the community would ever result in such techniques being developed or even scaling out the brute force approach is equally speculation. The more fundamental question here is whether the current timeframes are a problem for anyone or if there is any need to change the existing process. And that discussion seems to be off limits with the only choice being to switch to a different disto or start a new project if you don't think the existing approach is perfect. At this point that discussion is probably counterproductive for this release, but the 'open is better' suggestions have always been brushed rudely aside. At least there _is_ another distro suitable at least for testing purposes.
On Wed, May 18, 2011 at 9:01 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 5/18/11 5:05 AM, Ljubomir Ljubojevic wrote:
Tom, you are way off the point I was making. RHEL, Fedora, Debian, Ubuntu, all other distro's are *developed* and can change at any time.
That's why I said "he should've only chosen to compare CentOS to SL."
On 05/18/2011 08:01 AM, Les Mikesell wrote:
It was discussed, but that doesn't change anyone's mindset about open vs. closed processes or whether being more open and permitting community insight and participation would ultimately keep the project from going the way of Whitebox.
Hello Les,
CentOS is used on more web servers than Red Hat Enterprise Linux and Fedora combined ... it is not going anywhere.
Also, the slight decrease that was happening in Linux in general (which was mirrored by CentOS) in October of 2010 is also corrected.
http://w3techs.com/technologies/details/os-centos/all/all
Facebook uses thousands of CentOS servers. They are quite happy with it. Amazon EC2 has thousands of CentOS servers. They are also quite happy with it. We just became a fully supported OS on Microsoft Hyper-V.
Can we do a better job at some things, sure. But trust me, CentOS is going nowhere.
Thanks, Johnny Hughes
On 5/19/11, Johnny Hughes johnny@centos.org wrote:
Can we do a better job at some things, sure. But trust me, CentOS is going nowhere.
I think you might mean "CentOS is not going away" since "going nowhere" fast or slow is bad news for those waiting for the next version ;)
On Sun, May 15, 2011 at 5:12 PM, Gordon Messmer yinyang@eburg.com wrote:
Look at wikipedia's page describing CentOS. They include a column for the delay between the upstream release and CentOS's. For the 5 series, it looks like:
Release Delay 5 28d 5.1 25d 5.2 34d 5.3 69d 5.4 49d 5.5 44d 5.6 85d
Almost every release in the 5 series took longer than the initial release for 5.0. Even if you ignore the release of 5.6, there is a generally upward trend in the amount of time taken for each release. How could anyone reasonably claim that CentOS is NOT getting worse on release dates?
So, when you take 5.6 out of the mix (taking into account the three releases at once), the average time from Red Hat 5.x release to CentOS 5.x release is 41.5 days. And 5.5 was 44 days. Your point? Up until 5.6 the longest it took for a CentOS 5.x release was 69 days, 5.4 took 49 days and 5.5 took 44 days. Is that going up or down? Take 5.3 out of the mix (as well as the three-release 5.6) and you've got an average of 36 days. Just barely over a month. Even with 5.3 it averages about a month and a half. 5.6 (and 5.3) were the aberrations, not the average. Thanks for the figures. They don't prove your point.
I can't even begin to comprehend the logical failure behind the idea that because SL and CentOS are keeping up with each other that CentOS is not getting worse. Again, Dag interjected only to ask why any reasonable person would expect 6.1 to take only one month when 5.6 took three. The fact that there is a general trend toward longer release delays supports that question.
Again, three releases at once. Up until then, the previous two 5.x releases came down in the number of days between upstream release and CentOS rebuild. You've got the facts right in front of your nose and you still get it wrong. And I don't know what happened at release 5.3, but SL took 57 days on that one -- so I'm guessing something was added to the mix.
That's fine, but that's not what's being discussed.
So, on average (without 5.6) less than a month a half per release -- so a month for 6.1 is not that far off.
On 05/15/2011 07:00 PM, Ron Blizzard wrote:
So, when you take 5.6 out of the mix (taking into account the three releases at once), the average time from Red Hat 5.x release to CentOS 5.x release is 41.5 days. And 5.5 was 44 days. Your point?
There is a general trend toward longer delays between upstream and CentOS releases, with occasional anomalies of *extremely* long delays. That is the point.
Up until 5.6 the longest it took for a CentOS 5.x release was 69 days, 5.4 took 49 days and 5.5 took 44 days. Is that going up or down?
From the beginning of the series? Generally longer.
Take 5.3 out of the mix (as well as the three-release 5.6) and you've got an average of 36 days.
And all of 5.3, 5.4, 5.5, and 5.6 have taken longer than that.
Just barely over a month. Even with 5.3 it averages about a month and a half. 5.6 (and 5.3) were the aberrations, not the average. Thanks for the figures. They don't prove your point.
I think they do. Even when you cherry-pick the data as you did.
Tell you what: Plot the release delays on a graph using the release as the X axis and the delay as the Y axis. Based on that graph, plot the trend of the data. Even if you exclude the outlying data, I can't imagine a way to honestly plot a trend that isn't growing.
I can't even begin to comprehend the logical failure behind the idea that because SL and CentOS are keeping up with each other that CentOS is not getting worse. Again, Dag interjected only to ask why any reasonable person would expect 6.1 to take only one month when 5.6 took three. The fact that there is a general trend toward longer release delays supports that question.
Again, three releases at once.
For certain definitions of "at once". Upstream 6.0 was released in November. 5.6 was release about 2 months later, and work on C6 was stopped in order to get 5.6 out. 4.9 was out about a month after that. CentOS was, as far as we know, working on 4.9 and 5.6 at the same time, but not on 6.
Moreover, for the near future, there will continue to be multiple releases from upstream within a couple of months of each other. Is there any rational basis on which we should expect that the CentOS releases will no longer take several months under the same conditions that they've been faced with?
On 05/15/2011 05:12 PM, Gordon Messmer wrote:
The process around building CentOS has traditionally been very secretive, which makes the name "*Community* Enterprise OS" seem very inapt.
The community in CentOS that you write about was NEVER about building CentOS.
We have never said that anyone but the project would build it.
The community part is that we give it away for free and the community helps each other use it.
That is what this list used to be for. Before it turned into an completely unusable pile of crap, where a few people whine the same incessant demands, as if they are paying for something.
The community provided the QA team, they provide the answers to bugs.centos.org, they provide the technical answers here.
That is what the community does, that is what their role in the process is. This is not new. The project releases the distributions in our spare time. They are something that usually costs lots of money, but you get them for free. Because you get them for free, you help the project by spending time answering e-mail on the lists or by looking at the bugs and answering questions there. Or by helping in the forums, etc.
That is not what we are seeing here. What we are seeing here is a small group of people who think they are entitled to CentOS on their schedule and not on ours.
Well, we make CentOS because we use it in production. If you can also use it in production, great. If you can't use it, that is also great.
We are trying to provide more information on what is going on, but I would say that we already provide more information than any other distro out there. Certainly any enterprise distro out there.
On 5/16/2011 5:05 AM, Johnny Hughes wrote:
We have never said that anyone but the project would build it.
But you also didn't say that the project would lack the resources to do it in a timely manner or handle concurrent updates. In fact, I thought the project used to post goals for timeliness instead of just 'whenever'.
The community part is that we give it away for free and the community helps each other use it.
That is what this list used to be for.
People know how to use 5.x by now. I suspect we'd all rather be talking about how to use new features.
Before it turned into an completely unusable pile of crap, where a few people whine the same incessant demands, as if they are paying for something.
You spoiled us with speed up until the 5.3 update. We thought it was something we could count on...
Well, we make CentOS because we use it in production.
And you don't have a use for 6.x?
We are trying to provide more information on what is going on, but I would say that we already provide more information than any other distro out there. Certainly any enterprise distro out there.
You mean things like: http://release.debian.org/ http://bugs.debian.org/release-critical/ http://www.debian.org/devel/buildd/operation https://buildd.debian.org/ (w/links to build logs) https://buildd.debian.org/stats/
Doesn't leave much to post mailing list questions regarding status even if their release schedule is "whenever"... I can sort-of see why commercial distros that want to hurt their competition would hide this kind of information, but what's the point for Centos?
On 05/16/2011 10:41 AM, Les Mikesell wrote:
On 5/16/2011 5:05 AM, Johnny Hughes wrote:
We have never said that anyone but the project would build it.
But you also didn't say that the project would lack the resources to do it in a timely manner or handle concurrent updates. In fact, I thought the project used to post goals for timeliness instead of just 'whenever'.
The community part is that we give it away for free and the community helps each other use it.
That is what this list used to be for.
People know how to use 5.x by now. I suspect we'd all rather be talking about how to use new features.
Before it turned into an completely unusable pile of crap, where a few people whine the same incessant demands, as if they are paying for something.
You spoiled us with speed up until the 5.3 update. We thought it was something we could count on...
Well, we make CentOS because we use it in production.
And you don't have a use for 6.x?
We are trying to provide more information on what is going on, but I would say that we already provide more information than any other distro out there. Certainly any enterprise distro out there.
You mean things like: http://release.debian.org/ http://bugs.debian.org/release-critical/ http://www.debian.org/devel/buildd/operation https://buildd.debian.org/ (w/links to build logs) https://buildd.debian.org/stats/
Doesn't leave much to post mailing list questions regarding status even if their release schedule is "whenever"... I can sort-of see why commercial distros that want to hurt their competition would hide this kind of information, but what's the point for Centos?
The point is that we do not have a system built that can track that sort of stuff ... and we can either build packages or design systems to track stuff.
We are working on a new website design.
We opened up a new QAWeb.
We have an announce list.
As far as build logs are concerned, they reside on the build server ... where we had people try to "break into". That machine is now hidden and references to its name are also hidden. We can't have people pounding away against important servers ... there is no such thing as a completely secure setup. We therefore will not make our build machines open to the public.
On 5/16/2011 12:27 PM, Johnny Hughes wrote:
The point is that we do not have a system built that can track that sort of stuff ... and we can either build packages or design systems to track stuff.
You don't really have to design a system for build automation/tracking since there are several free ones available. Of course there is a tradeoff in terms of how quickly the automation would win back the time it takes to configure it.
We are working on a new website design.
We opened up a new QAWeb.
We have an announce list.
All great, and much appreciated, particularly compared to previous postings that implied that nothing needed to change or was ever going to. Still, I don't see how these help with the underlying issue of resources unless the bottleneck is in post-build QA.
As far as build logs are concerned, they reside on the build server ... where we had people try to "break into". That machine is now hidden and references to its name are also hidden. We can't have people pounding away against important servers ... there is no such thing as a completely secure setup. We therefore will not make our build machines open to the public.
Agreed on the security comment, hence the concern about timely updates. It is pretty much a given that any public site will be hit with all known exploit attempts, but it is somewhat unsettling to think that the project itself considers that to be a problem. But, most of both the 'pounding' and security issues can be handled with a simple caching reverse-proxy server easily configured in squid/apache/nginx, etc.. And with build automation frameworks like jenkins/hudson, the results and logs are collated on a central server that mostly does scheduling, not the actual work: http://ci.jenkins-ci.org/builds.
On 05/16/11 11:24 AM, Les Mikesell wrote:
it is somewhat unsettling to think that the project itself considers that to be a problem.
consider what might happen if a core build server for a project as widely used as centos gets penetrated and carefully targetted to slip trojans unnoticed into the final product.... this woudl be a holy grail to the sort of international espionage that is taking place today.
be scared, be very scared.
On 5/16/2011 1:43 PM, John R Pierce wrote:
On 05/16/11 11:24 AM, Les Mikesell wrote:
it is somewhat unsettling to think that the project itself considers that to be a problem.
consider what might happen if a core build server for a project as widely used as centos gets penetrated and carefully targetted to slip trojans unnoticed into the final product.... this woudl be a holy grail to the sort of international espionage that is taking place today.
be scared, be very scared.
Yes, but assuming they eat their own dog food and are running the same thing we are, if their servers are penetrated, yours will too even before whatever they are building ships. And it is something that debian seems to be able to handle. In any case, with full automation it would be easy enough to duplicate the final build on a trusted server and compare the results before distribution. Or for someone else to do it to verify from an outside perspective.
On 05/16/2011 02:46 PM, Les Mikesell wrote:
On 5/16/2011 1:43 PM, John R Pierce wrote:
On 05/16/11 11:24 AM, Les Mikesell wrote:
it is somewhat unsettling to think that the project itself considers that to be a problem.
consider what might happen if a core build server for a project as widely used as centos gets penetrated and carefully targetted to slip trojans unnoticed into the final product.... this woudl be a holy grail to the sort of international espionage that is taking place today.
be scared, be very scared.
Yes, but assuming they eat their own dog food and are running the same thing we are, if their servers are penetrated, yours will too even before whatever they are building ships. And it is something that debian seems to be able to handle. In any case, with full automation it would be easy enough to duplicate the final build on a trusted server and compare the results before distribution. Or for someone else to do it to verify from an outside perspective.
There is not a server in the world that I could not break into if I was on the same subnet ... and I am not even that smart.
Johnny Hughes wrote:
There is not a server in the world that I could not break into if I was on the same subnet ... and I am not even that smart.
maybe but you have the distinct advantage of having your private trojans in every centos system out there ;-)
On 05/16/2011 01:24 PM, Les Mikesell wrote:
On 5/16/2011 12:27 PM, Johnny Hughes wrote:
The point is that we do not have a system built that can track that sort of stuff ... and we can either build packages or design systems to track stuff.
You don't really have to design a system for build automation/tracking since there are several free ones available. Of course there is a tradeoff in terms of how quickly the automation would win back the time it takes to configure it.
We are working on a new website design.
We opened up a new QAWeb.
We have an announce list.
All great, and much appreciated, particularly compared to previous postings that implied that nothing needed to change or was ever going to. Still, I don't see how these help with the underlying issue of resources unless the bottleneck is in post-build QA.
As far as build logs are concerned, they reside on the build server ... where we had people try to "break into". That machine is now hidden and references to its name are also hidden. We can't have people pounding away against important servers ... there is no such thing as a completely secure setup. We therefore will not make our build machines open to the public.
Agreed on the security comment, hence the concern about timely updates. It is pretty much a given that any public site will be hit with all known exploit attempts, but it is somewhat unsettling to think that the project itself considers that to be a problem. But, most of both the 'pounding' and security issues can be handled with a simple caching reverse-proxy server easily configured in squid/apache/nginx, etc.. And with build automation frameworks like jenkins/hudson, the results and logs are collated on a central server that mostly does scheduling, not the actual work: http://ci.jenkins-ci.org/builds.
Wonderful except it is a build server ... and certain things need to function without a proxy.
It doesn't matter though, because regardless of what I do, it is not enough for you.
I am already busting my ass to give a $2500.00 piece of software to you for free, to use as many times as you want to ... saving you as much money as $2500.00 x <number_you_run>
Now, not only do I need to bust my ass to provide it to you for free, but I also need to do other things for you to. I need to provide you access to stuff and I need to track things in a different way and I need to setup elaborate systems. AND, I need to tell you exactly how I build it too.
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
on 5/16/2011 11:47 AM Johnny Hughes spake the following:
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
I hear ya Johnny... The only hurry I am in over 6 getting out is that FINALLY some of the whining will stop... For a little while... I saw the same sort of complaints at Whitebox, and it will never stop...
I hope you don't just get fed up with the bitching and stop the project...
No need to respond... Just go on doing what you need to do...
On 5/16/2011 1:47 PM, Johnny Hughes wrote:
Agreed on the security comment, hence the concern about timely updates. It is pretty much a given that any public site will be hit with all known exploit attempts, but it is somewhat unsettling to think that the project itself considers that to be a problem. But, most of both the 'pounding' and security issues can be handled with a simple caching reverse-proxy server easily configured in squid/apache/nginx, etc.. And with build automation frameworks like jenkins/hudson, the results and logs are collated on a central server that mostly does scheduling, not the actual work: http://ci.jenkins-ci.org/builds.
Wonderful except it is a build server ... and certain things need to function without a proxy.
That's not a particular problem. You can have a public reverse-proxy that knows how to access a subset of an otherwise firewalled or certificate-requiring site without affecting the other ways you can access the source side directly.
It doesn't matter though, because regardless of what I do, it is not enough for you.
I am already busting my ass to give a $2500.00 piece of software to you for free, to use as many times as you want to ... saving you as much money as $2500.00 x<number_you_run>
Now, not only do I need to bust my ass to provide it to you for free, but I also need to do other things for you to. I need to provide you access to stuff and I need to track things in a different way and I need to setup elaborate systems. AND, I need to tell you exactly how I build it too.
You are completely missing the point here, which is not to beat you up for not doing better with limited resources. I believe that by making the process and its problems public, someone will help solve those problems as they do in many, many other projects where the work is open. That both reduces the need for you to bust your ass and speeds up the availability for everyone else. You may not agree that this would happen and of course it is your call, but please don't mischaracterize a suggestion that has been shown to work elsewhere as a personal demand for anything.
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
If you could look at this objectively from a user's side, would you be happy with a timeframe rounding up to a year?
On 05/16/11 12:38 PM, Les Mikesell wrote:
I believe that by making the process and its problems public, someone will help solve those problems as they do in many, many other projects where the work is open.
a very wise man[1] once said adding more bodies to a late project just makes it later. 9 women can't make a baby in 1 month.
this is NOT a software development project, where pieces of it can be torn off and worked on independently, then later integrated. this is a software build-and-integrate project where all the pieces have to be fit together and the bulk of the hard work is reverse engineering and recreating the correct build environment.
[1] Fredrick P. Brooks, The Mythical Man-Month, 1975. 36 years later, this book's fundamental premises are just as valid.
On 5/16/2011 2:52 PM, John R Pierce wrote:
On 05/16/11 12:38 PM, Les Mikesell wrote:
I believe that by making the process and its problems public, someone will help solve those problems as they do in many, many other projects where the work is open.
a very wise man[1] once said adding more bodies to a late project just makes it later. 9 women can't make a baby in 1 month.
If we were talking about a month, well probably no one would be talking...
this is NOT a software development project, where pieces of it can be torn off and worked on independently, then later integrated.
And yet, there were 3 completely unrelated paths where only one had progress at a time. Or so we've been told. And that's not exactly a surprising situation even though they may not coincide frequently.
this is a software build-and-integrate project where all the pieces have to be fit together and the bulk of the hard work is reverse engineering and recreating the correct build environment.
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
[1] Fredrick P. Brooks, The Mythical Man-Month, 1975. 36 years later, this book's fundamental premises are just as valid.
I wonder what he would have said about google's approach to, say, translation or voice recognition where the results depend on availability of massive amounts of input as much as anything else.
On 05/16/11 1:18 PM, Les Mikesell wrote:
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
so you are volunteering to take over 4.next or 5.x or whatever when the time comes ? you can come up with the build infrastructure and develop this automation in the meantime? I'd suggest starting with recreating 5.6 by working from 5.5 and the RHEL 5,6 SRPMs exclusively. let us know how long it takes from scratch, ok? you don't mind that we-the-community would want our packagers vetted by demonstrating the ability to deliver... consider this a test run.
On 5/16/2011 3:38 PM, John R Pierce wrote:
On 05/16/11 1:18 PM, Les Mikesell wrote:
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
so you are volunteering to take over 4.next or 5.x or whatever when the time comes ? you can come up with the build infrastructure and develop this automation in the meantime? I'd suggest starting with recreating 5.6 by working from 5.5 and the RHEL 5,6 SRPMs exclusively. let us know how long it takes from scratch, ok? you don't mind that we-the-community would want our packagers vetted by demonstrating the ability to deliver... consider this a test run.
No, but I'm not the only member of the public. And your suggestion of starting by reproducing someone else's work from scratch instead of building on it would be like Linus telling everyone to just write their own unix-like kernel before trying to add to it. If he had done that instead of letting others build on the existing work we wouldn't be talking about usable Linux distributions today at all.
On Mon, May 16, 2011 at 3:50 PM, Les Mikesell lesmikesell@gmail.com wrote:
No, but I'm not the only member of the public. And your suggestion of starting by reproducing someone else's work from scratch instead of building on it would be like Linus telling everyone to just write their own unix-like kernel before trying to add to it. If he had done that instead of letting others build on the existing work we wouldn't be talking about usable Linux distributions today at all.
And yet that's what the CentOS developers originally had to do (and apparently had to do all over again with 6.0). So a little respect and gratitude would be in order, don't you think?
On 05/16/2011 11:50 PM, Les Mikesell wrote:
On 5/16/2011 3:38 PM, John R Pierce wrote:
On 05/16/11 1:18 PM, Les Mikesell wrote:
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
so you are volunteering to take over 4.next or 5.x or whatever when the time comes ? you can come up with the build infrastructure and develop this automation in the meantime? I'd suggest starting with recreating 5.6 by working from 5.5 and the RHEL 5,6 SRPMs exclusively. let us know how long it takes from scratch, ok? you don't mind that we-the-community would want our packagers vetted by demonstrating the ability to deliver... consider this a test run.
No, but I'm not the only member of the public. And your suggestion of starting by reproducing someone else's work from scratch instead of building on it would be like Linus telling everyone to just write their own unix-like kernel before trying to add to it. If he had done that instead of letting others build on the existing work we wouldn't be talking about usable Linux distributions today at all.
The main "fear" the developers have is that somebody could steal their work and come up with another RHEL clone easily if they release their build system & scripts. I think this is obvious by now. It is also pretty obvious that the developers have a strong hope that by keeping CentOS closed, somebody will notice their skills and will pay them a fortune for their knowledge by hiring them. This is my opinion and it is based on what I read on this list during the last months.
On Mon, May 16, 2011 at 4:00 PM, Radu Gheorghiu radu@pengooin.net wrote:
The main "fear" the developers have is that somebody could steal their work and come up with another RHEL clone easily if they release their build system & scripts. I think this is obvious by now. It is also pretty obvious that the developers have a strong hope that by keeping CentOS closed, somebody will notice their skills and will pay them a fortune for their knowledge by hiring them. This is my opinion and it is based on what I read on this list during the last months.
What a load of undiluted crap. They've been doing this for over seven years. But nothing is stopping you from starting your own Red Hat rebuild project. You *know* so much better how it *should* be done. Enlighten us. Actually do it.
On 05/17/2011 12:15 AM, Ron Blizzard wrote:
On Mon, May 16, 2011 at 4:00 PM, Radu Gheorghiuradu@pengooin.net wrote:
The main "fear" the developers have is that somebody could steal their work and come up with another RHEL clone easily if they release their build system& scripts. I think this is obvious by now. It is also pretty obvious that the developers have a strong hope that by keeping CentOS closed, somebody will notice their skills and will pay them a fortune for their knowledge by hiring them. This is my opinion and it is based on what I read on this list during the last months.
What a load of undiluted crap.
Please keep this for yourself.
They've been doing this for over seven years. But nothing is stopping you from starting your own Red Hat rebuild project. You *know* so much better how it *should* be done. Enlighten us. Actually do it.
I never said I want to do it. I only said what the devs are obviously doing. Maybe 7+ years is too much waiting for somebody to come and fill their pockets.
On 05/16/11 2:41 PM, Radu Gheorghiu wrote:
I never said I want to do it.
ah, so what DID you say? you want someone unspecified to do a better/different job for you than someone else is already doing for free ?
man, its easy to volunteer other people from the comfort of your desk.
On 05/17/2011 12:47 AM, John R Pierce wrote:
On 05/16/11 2:41 PM, Radu Gheorghiu wrote:
I never said I want to do it.
ah, so what DID you say? you want someone unspecified to do a better/different job for you than someone else is already doing for free ?
man, its easy to volunteer other people from the comfort of your desk.
If you would re-read my email you would see that I only expressed my thoughts. I did not ask for somebody else to do it. If this is your reaction when somebody says what he thinks, you got issues.
On Tue, May 17, 2011 at 12:41:23AM +0300, Radu Gheorghiu wrote:
On 05/17/2011 12:15 AM, Ron Blizzard wrote:
What a load of undiluted crap.
Please keep this for yourself.
Why when it's the truth. Does the truth hurt?
I never said I want to do it. I only said what the devs are obviously doing. Maybe 7+ years is too much waiting for somebody to come and fill their pockets.
s/want to do it/can do it/
John
On 05/17/2011 12:51 AM, John R. Dennison wrote:
On Tue, May 17, 2011 at 12:41:23AM +0300, Radu Gheorghiu wrote:
On 05/17/2011 12:15 AM, Ron Blizzard wrote:
What a load of undiluted crap.
Please keep this for yourself.
Why when it's the truth. Does the truth hurt?
It may be the truth from your point of view. What I said in my initial post is what many companies i work with feel. If some of you can't say anything smarter than "crap", then please focus for a few seconds before posting.
I never said I want to do it. I only said what the devs are obviously doing. Maybe 7+ years is too much waiting for somebody to come and fill their pockets.
s/want to do it/can do it/
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, May 17, 2011 at 12:55:59AM +0300, Radu Gheorghiu wrote:
If some of you can't say anything smarter than "crap", then please
Please do the rest of us a favor and take your own advice.
John
On Tue, 17 May 2011, Radu Gheorghiu wrote:
The main "fear" the developers have is that somebody could steal their work and come up with another RHEL clone easily if they release their build system & scripts.
I think this is obvious by now.
'obvious' to you or not, such is not the case with my view of the matter, nor indeed my practice .... not that CentOS is just the fruit of a binary build solution. The attention to 'getting it right' the first time, the trademark and branding changes, the art, the bug tracker, the mirror network and its 'backside management,' the mailing lists, IRC, forum, and wiki and more are 'part of the package' as well.
Shall we also stop and describe how to set up Mailman, administer IRC channels, in formal detail? Doing so will do nothing to attain the 'goal' which I assume a vast 'silent majority' are eagerly awaiting
Some others have set up alternative approaches ** even working forward from CentOS' of build SRPMS ** -- SME Server, and ClearOS come to mind, but their goals differ
CentOS is not diminished by Scientific Linux, nor vice versa. I have communicated cordially with them on matters of common interest for years
SME has such radically different goals as a project that people do not recognize the current CentOS roots; ClearOS again had its own 'take' on the release contents, and has recently announced an intent to fork away from using CentOS SRPMs after several years following CentOS. Some of the build group from each were in the QA group for a while. There are other RPM based, upstream derived, rebuild projects out there as well, that a person has to look closely, and know the history, or read the sources, to see where they came from
I've repeatedly published my approach to the build solve, including a solution written after solving the parts of upstream's '6' sources in which I am interested. I have such running in private release. I've offered several times here to offer private guidance 'through the rough spots' for people attempting such a upstream cloning
Some of the earliest content in the CentOS wiki was articles about build environments, and building as non-root, predating the transition by serious builders to mock and other 'in a clean chroot' approaches
But the build for the first bootstrap '6' does not encounter the same issues that '5' or '4' encountered. I've said that as clearly as I can before, as have others on the CentOS build group, and people who treat a rebuild as a thought experiment to be talked to death, will NEVER understand that. One has to DO it, to see and understand the way the solution to the rebuild problem mutates over time
I see later in this thread 'conspiracy theory' reference' to a 'massive code base' --- what a crock. Build-systems dating from the old Red Hat RHL 'beehive' fifteen years ago started as Rube Goldberg contraptions needing constant love and attention from their tenders. I am told by one such 'tender' from that era, that it always seemed to break after midnight, necessitating sometimes 'driving back to office' to repair and restart
The 'state of the art' as to packaging, and automation change over time, but there still needs to be a person who understands the build automation system, able to go in a "'kill' a hung job" and experienced eyes to diagnose and patch around the inevitable problems that surface in the final few percent of the packages.
And anyone who thinks that patching 'anaconda' (the installer) is a well defined task has no conception of the enormity of the changes over time that anaconda has gone through. I am tremendously unhappy with the changes with the anaconda TUI mode under upstream's '6' and once a CentOS 6 emerges, I can foresee much support load with people adversely affected
A couple have actually followed through the work of rebuilding and integrating the upstream's '6' sources (not the people who would rather carp and troll here, of course), and I've mentioned privately helping other people building the latest upstream sources from scratch with their efforts. At least two have working sub-sets to their interest and project goal, complete with installers, at the upstream's '6' level
heck -- In looking at my local developmental 'crash and burn' laptop, which started live as a CentOS 5 unit 14 months ago, I see over 30 ** POST ** upstream '6' level packages. Looking, I see that my day-to-day office developmental workstation (a bit over three years old at this point) has 1101 of 2287 total packages that are local deviations from C 5 (mostly pushing in financial and statistical tool-chains, but also developmental tools ... automake, m4, libtool, and so forth)
Sometimes to reproduce a bug, I need to deploy a fresh machine image, just to make sure my local changes to not mask something -- the changes by upstream to the named configuration files generation comes to mind as one I needed to 'revert' back to a clean install, to see what in the world the reporter was seeing
It is a simply false to fact to reach your 'obvious' conclusion
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
-- Russ herrold
On Mon, May 16, 2011 at 06:08:47PM -0400, R P Herrold wrote:
other RPM based, upstream derived, rebuild projects out there as well, that a person has to look closely, and know the history, or read the sources, to see where they came from
And then there's commercial projects, such as Citrix Xen Server (one of the leading competitors to VMware). I wonder what that's built on. Let's look...
# cat /etc/redhat-release XenServer release 5.6.0-31188p (xenenterprise)
# rpm -q centos-release centos-release-5-4.el5.centos.1
Dang; that evil CentOS project gets everywhere...
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
-- Russ herrold
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining.... You could be producing happy rainbows out of thin air, and you would probably still have a few percentage points of the users complaining....
Just remember that although most are silent, they are being silent so you can get something done besides having to defend yourselves...
Scott Silva wrote:
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining....You could be producing happy rainbows out of thin air, and you would probably still have a few percentage points of the users complaining....
There will be *no* "happy rainbows" here, and if you bring in unicorns, *then* you'll see flames.
mark
On 05/17/2011 09:46 AM, Scott Silva wrote:
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
-- Russ herrold
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining.... You could be producing happy rainbows out of thin air, and you would probably still have a few percentage points of the users complaining....
It is *Millions* of CentOS users :D
And there are 4200 subscribed to this list.
Johnny Hughes wrote:
On 05/17/2011 09:46 AM, Scott Silva wrote:
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining....
<snip>
It is *Millions* of CentOS users :D
And there are 4200 subscribed to this list.
Must be millions: http://linux.slashdot.org/story/11/05/16/2022259/Microsoft-To-Support-CentOS-Linux-In-Hyper-V
M$ wouldn't even see anything smaller.
mark
on 5/17/2011 9:36 AM m.roth@5-cent.us spake the following:
Johnny Hughes wrote:
On 05/17/2011 09:46 AM, Scott Silva wrote:
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining....
<snip> > It is *Millions* of CentOS users :D > > And there are 4200 subscribed to this list.
Must be millions: http://linux.slashdot.org/story/11/05/16/2022259/Microsoft-To-Support-CentOS-Linux-In-Hyper-V
M$ wouldn't even see anything smaller.
mark
The buyout will be next... ;)
On Wednesday, May 18, 2011 02:58 AM, Scott Silva wrote:
on 5/17/2011 9:36 AM m.roth@5-cent.us spake the following:
Johnny Hughes wrote:
On 05/17/2011 09:46 AM, Scott Silva wrote:
on 5/16/2011 3:08 PM R P Herrold spake the following: <<snip>>
[I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment]
Don't feel too bad... Out of the thousands of CentOS users, and the hundreds subscribed to this list, I only see a dozen or so people complaining....
<snip> > It is *Millions* of CentOS users :D > > And there are 4200 subscribed to this list.
Must be millions: http://linux.slashdot.org/story/11/05/16/2022259/Microsoft-To-Support-CentOS-Linux-In-Hyper-V
M$ wouldn't even see anything smaller.
markThe buyout will be next... ;)
Please Johnny, don't sell us out!
On Mon, May 16, 2011 at 3:18 PM, Les Mikesell lesmikesell@gmail.com wrote:
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
You know Les, you're talking in hypotheticals. Johnny and the other CentOS developers are actually *doing* the work. Everything is "easy" when you're not actually doing it. If you know so much about *how* it should be done, why don't you and your like-minded friends start your own rebuild project? That would give you something else to do rather than sniping from the sidelines here.
On 05/16/11 1:51 PM, Ron Blizzard wrote:
On Mon, May 16, 2011 at 3:18 PM, Les Mikeselllesmikesell@gmail.com wrote:
Yes, but whatever can't be automated here should benefit from doing the trial-and-error in parallel. And the potential improvements might come in the automation process as much as the grunge work - you can't really predict how an open project will develop.
You know Les, you're talking in hypotheticals. Johnny and the other CentOS developers are actually *doing* the work. Everything is "easy" when you're not actually doing it. If you know so much about *how* it should be done, why don't you and your like-minded friends start your own rebuild project? That would give you something else to do rather than sniping from the sidelines here.
no, no. he wants someone ELSE to do that. see his last response to me.
i'm done with this thread. <ker-flush>
On Mon, May 16, 2011 at 03:51:22PM -0500, Ron Blizzard wrote:
You know Les, you're talking in hypotheticals. Johnny and the other CentOS developers are actually *doing* the work. Everything is "easy" when you're not actually doing it. If you know so much about *how* it should be done, why don't you and your like-minded friends start your own rebuild project? That would give you something else to do rather than sniping from the sidelines here.
+1000000000000000000000000000000000000000000000000000000000000000000000000000
John
On May 16, 2011, at 11:47 AM, Johnny Hughes wrote:
Now, not only do I need to bust my ass to provide it to you for free, but I also need to do other things for you to. I need to provide you access to stuff and I need to track things in a different way and I need to setup elaborate systems. AND, I need to tell you exactly how I build it too.
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
---- can't say that in all the years I've been using FOSS/Linux that I've ever seen the maintainers have such open disdain for their users. Clearly they have gotten a massive code base for free and though the cost of assembling it into a redistributable system is not inconsequential, it's clear that if this attitude was prevalent, we wouldn't have the massive code base available as it were.
Craig
On 05/16/2011 04:10 PM, Craig White wrote:
On May 16, 2011, at 11:47 AM, Johnny Hughes wrote:
Now, not only do I need to bust my ass to provide it to you for free, but I also need to do other things for you to. I need to provide you access to stuff and I need to track things in a different way and I need to setup elaborate systems. AND, I need to tell you exactly how I build it too.
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
can't say that in all the years I've been using FOSS/Linux that I've ever seen the maintainers have such open disdain for their users. Clearly they have gotten a massive code base for free and though the cost of assembling it into a redistributable system is not inconsequential, it's clear that if this attitude was prevalent, we wouldn't have the massive code base available as it were.
And yet, we do have the massive code base. And Red Hat did not have to publish their build system, their build logs, their hidden dependencies, or anything else. All the had to do was follow the GPL.
CentOS also publishes all our changes and follows the GPL. We publish build scripts and other things that Red Hat would never publish. And I am the bad guy. Really?
On Mon, May 16, 2011 at 02:10:28PM -0700, Craig White wrote:
can't say that in all the years I've been using FOSS/Linux that I've ever seen the maintainers have such open disdain for their users.
You're missing the point. The disdain, if that's truly what Johnny is feeling, is only directed at a teeny tiny inconsequential portion of the of the user base. This would be the leeches that do nothing but bitch about those providing the free gravy that they use in their businesses but yet give absolutely nothing back in terms of tangible work or effort.
Besides, that imaginary shackle you have around your ankle keeping you (used collectively) here isn't locked; you're free to find alternatives.
John
On Mon, May 16, 2011 at 4:10 PM, Craig White craig.white@ttiltd.com wrote:
can't say that in all the years I've been using FOSS/Linux that I've ever seen the maintainers have such open disdain for their users. Clearly they have gotten a massive code base for free and though the cost of assembling it into a redistributable system is not inconsequential, it's clear that if this attitude was prevalent, we wouldn't have the massive code base available as it were. <<
"Disdain for users?" You mean "disgust for constant whiners," don't you? Strange to say, I share the developers "disdain."
On Mon, 16 May 2011 13:47:30 -0500 Johnny Hughes johnny@centos.org wrote:
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
Johnny please don't take this personally. I don't know who came with the expression:
"When you fight with a pig, you both get dirty - but the pig likes it"
They like it and your blood pressure rise. Not worth it. Don't listen to them.
PS. I'm one of the silent majority! I run a few v4 and v5. Thanks for the hard work.
on 5/16/2011 2:45 PM centos@911networks.com spake the following:
On Mon, 16 May 2011 13:47:30 -0500 Johnny Hughes johnny@centos.org wrote:
Can't you ungrateful bastards take the free software I make by following the licensing requirements and be happy with that?
Johnny please don't take this personally. I don't know who came with the expression:
"When you fight with a pig, you both get dirty - but the pig likes it"
They like it and your blood pressure rise. Not worth it. Don't listen to them.
PS. I'm one of the silent majority! I run a few v4 and v5. Thanks for the hard work.
+1000000000000000000001
On May 15, 2011, at 3:52 AM, Ron Blizzard wrote:
You're leaving out release 4.9. You're also leaving out the fact that two major holidays occurred during the time *frame* that these three releases needed to be built. You're also leaving out the fact (as mentioned by one of the developers) that they had to start from scratch on 6.0 -- that they'll be "set up" for 6.1 when it comes out. You're also leaving out the fact that SL had to rebuild the same three releases -- and they're still working on the last of those -- so the amount of time it's taking CentOS developers squares with the amount of time required by the SL developers.
---- but you're leaving out a very important distinction - SL released all the updates so the lack of a 5.6 release by SL is merely the installer disc's which is significant only to people who are looking to install SL on hardware that is newly supported by 5.6 and not 5.5. Their updated 5.6 packages (and the packages of primary concern are the security updates) have been available for some time - sooner than CentOS 5.6 packages. I think the time factor squaring is relevant only when you use the milestone targets.
Craig
On 5/16/2011 11:11 AM, Craig White wrote:
but you're leaving out a very important distinction - SL released all the updates so the lack of a 5.6 release by SL is merely the installer disc's which is significant only to people who are looking to install SL on hardware that is newly supported by 5.6 and not 5.5. Their updated 5.6 packages (and the packages of primary concern are the security updates) have been available for some time - sooner than CentOS 5.6 packages. I think the time factor squaring is relevant only when you use the milestone targets.
To be fair, there is another distinction in that the SL updates were more of a rolling release that may not have been built in an environment that matched upstream as precisely as the Centos version. But since we don't know the details of that environment it is hard to know whether to expect any practical differences as a result. Without more to go on, my gut feeling is that I would have preferred security updates to not be delayed by problems building a new anaconda/installer - and that if yum can't deal with updating components in any order the distribution is inherently broken anyway. As it happens, I think I have the main internet-exposed servers updated and the exploit attempts I was seeing were aimed at something fixed in 5.4 anyway - but I was still worried about things I might not have seen...
On 05/12/2011 01:08 AM, Mark Bradbury wrote:
> > Do you expect the C6.0 -> C6.1 differences to be more complex, or less > complex than the C5.5 -> C5.6 differences ? > > And given that C5.6 took 3 months, are there any reasons why C6.1 would > take no more than 1 month ? Get over yourself Dag ... for goodness sake.Why? seems like a valid point to me.
1. Have you, or anyone else, noticed the speed of the CentOS-5 and CentOS-4 updates recently? We have spread out the building and checking up updates .. there has been a marked improvement is release speed for updates.
2. Have you, or anyone else, noticed that we have started pushing out the upstream EL Fastrack channel for CentOS-5. In CentOS it is named fasttrack (spelling) on our end due to upstream IP restrictions.
http://mirror.centos.org/centos/5/fasttrack/
3. Have you, or anyone else, noticed the QA tracking site that is open to the public?
http://qaweb.dev.centos.org/qa/
There is a dashboard of recent events:
http://qaweb.dev.centos.org/dashboard
There is even an RSS feed:
http://qaweb.dev.centos.org/feed
Most of the names who are posting there and taking action are NOT CentOS Project guys, but community people ... isn't that what people were asking for?
4. Have you, or anyone else, noticed the aggregated list of status announcements that we now have? The forum moderators are great and they have started an announcement forum area where they aggregate important information:
http://www.centos.org/modules/newbb/viewforum.php?forum=53
==================================================
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes. Nothing could be further from the truth.
Johnny Hughes wrote:
On 05/12/2011 01:08 AM, Mark Bradbury wrote:
> > Do you expect the C6.0 -> C6.1 differences to be more complex, or less > complex than the C5.5 -> C5.6 differences ? > > And given that C5.6 took 3 months, are there any reasons why C6.1 would > take no more than 1 month ? Get over yourself Dag ... for goodness sake.Why? seems like a valid point to me.
- Have you, or anyone else, noticed the speed of the CentOS-5 and
CentOS-4 updates recently? We have spread out the building and checking up updates .. there has been a marked improvement is release speed for updates.
Yes - noted and appreciated
- Have you, or anyone else, noticed that we have started pushing out
the upstream EL Fastrack channel for CentOS-5. In CentOS it is named fasttrack (spelling) on our end due to upstream IP restrictions.
Yes noted
- Have you, or anyone else, noticed the QA tracking site that is open
to the public?
http://qaweb.dev.centos.org/qa/
There is a dashboard of recent events:
http://qaweb.dev.centos.org/dashboard
There is even an RSS feed:
http://qaweb.dev.centos.org/feed
Most of the names who are posting there and taking action are NOT CentOS Project guys, but community people ... isn't that what people were asking for?
Yes - I even saw a calendar with some target and milestones
- Have you, or anyone else, noticed the aggregated list of status
announcements that we now have? The forum moderators are great and they have started an announcement forum area where they aggregate important information:
http://www.centos.org/modules/newbb/viewforum.php?forum=53
==================================================
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes. Nothing could be further from the truth.
Please note there is a largely silent majority that appreciates very much what the team does, is doing to improve and listening to suggestions Keep up the great work - Thanks
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/12/2011 09:49 AM, Rob Kampen wrote:
Johnny Hughes wrote:
On 05/12/2011 01:08 AM, Mark Bradbury wrote:
> > Do you expect the C6.0 -> C6.1 differences to be more complex, or less > complex than the C5.5 -> C5.6 differences ? > > And given that C5.6 took 3 months, are there any reasons why C6.1 would > take no more than 1 month ? Get over yourself Dag ... for goodness sake.Why? seems like a valid point to me.
- Have you, or anyone else, noticed the speed of the CentOS-5 and
CentOS-4 updates recently? We have spread out the building and checking up updates .. there has been a marked improvement is release speed for updates.
Yes - noted and appreciated
- Have you, or anyone else, noticed that we have started pushing out
the upstream EL Fastrack channel for CentOS-5. In CentOS it is named fasttrack (spelling) on our end due to upstream IP restrictions.
Yes noted
- Have you, or anyone else, noticed the QA tracking site that is open
to the public?
http://qaweb.dev.centos.org/qa/
There is a dashboard of recent events:
http://qaweb.dev.centos.org/dashboard
There is even an RSS feed:
http://qaweb.dev.centos.org/feed
Most of the names who are posting there and taking action are NOT CentOS Project guys, but community people ... isn't that what people were asking for?
Yes - I even saw a calendar with some target and milestones
- Have you, or anyone else, noticed the aggregated list of status
announcements that we now have? The forum moderators are great and they have started an announcement forum area where they aggregate important information:
http://www.centos.org/modules/newbb/viewforum.php?forum=53
==================================================
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes. Nothing could be further from the truth.
Please note there is a largely silent majority that appreciates very much what the team does, is doing to improve and listening to suggestions Keep up the great work - Thanks
+1
Steve Clark wrote on 05/12/2011 10:15 AM:
Please note there is a largely silent majority that appreciates very much what the team does, is doing to improve and listening to suggestions Keep up the great work - Thanks
+1
++1
Please trim your posts. 60+ included lines and >> 2k characters for for a two character reply amounts to a very poor signal to noise ratio. Looks like worse than -30dB.
Phil
<big snip>
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes. Nothing could be further from the truth.
Please note there is a largely silent majority that appreciates very much what the team does, is doing to improve and listening to suggestions Keep up the great work - Thanks
<even bigger +1>
On Thu, 2011-05-12 at 09:49 -0400, Rob Kampen wrote:
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes. Nothing could be further from the truth.
Johnny, don't let this type of comment upset you as:
Please note there is a largely silent majority that appreciates very much what the team does, is doing to improve and listening to suggestions Keep up the great work - Thanks
+1 Louis
On 5/12/2011 8:37 AM, Johnny Hughes wrote:
It does not seem to matter what we try to do, what we get is petty comments about how nothing changes.
I think that will change to the extent that the project changes are visible. Thank you for posting all the links.
On Tuesday, May 10, 2011 09:12:59 PM Dag Wieers wrote:
And given that C5.6 took 3 months, are there any reasons why C6.1 would take no more than 1 month ?
I can easily think of a few. 4.9 and 6.0 are two of those few.
Again, I'll note that SL is just now releasing the second beta of 5.6 this Friday. Not the final SL 5.6. Not to try to make SL look bad in any way, but to highlight that the triple-threat of 6.0, 5.6, and 4.9 is/was hard on both projects.
CentOS chose to do 5.6 and 4.9 before 6.0; CentOS is later with 6.0. SL chose to do 6.0 first; they had 6.0 out first, and 4.9 followed, and 5.6 is not yet out. I don't consider a beta or alpha or even an RC release as being 'out' either.
And again I'm not being critical of either project; both do a fantastic job. They had and have different priorities, and with a CentOS 5.6 release behind us we now see the effect of those different priorities.
On Tue, 2011-05-10 at 12:13 +0200, Ljubomir Ljubojevic wrote:
Alain Péan wrote:
The problem is that when C6.0 will be released, it is likely that RHEL 6.1 will be already released. So there will be no security updates for C6.0, and it will be better to stay under SL6, until the release of C6.1. I already installed three machines under SL6, and it works fine.
Alain
Once 6.0 packages are figured out (how to compile them), newer versions of those packages in 6.1 will be much easier to compile, so I expect no more then one month to pass from C6.0 to C6.1
---- Considering that it took them 3 months to get out the 5.6 update and that upstream is adding packages that weren't ready when 6.0 was released, I would think that one month is highly optimistic but two things are certain. Upstream released exactly 6 months ago and still nothing and apparently today's target date has slipped, and 2) until CentOS admits that there is a problem, nothing will actually change.
Craig
On Tuesday, May 10, 2011 09:17:39 PM Craig White wrote:
Upstream released exactly 6 months ago and still nothing and apparently today's target date has slipped, and 2) until CentOS admits that there is a problem, nothing will actually change.
Please read the CentOS-devel list and IRC channel. There are some changes going on WRT visibility of the process, and time will tell if that sticks.
My gut feel, not being one of the developers doing this, is that once the package build order and buildroots are figured out for 6.0 that 6.1 should be far less work. But I reserve the right to be wrong.
How long it will take is of course anyone's guess; after all, it's been quite a while since 5.6's release, and SL, as fast as they were with 6.0, doesn't have a 5.6 full release out (beta 2 is due this Friday, but that's a beta and not a production release. Of course, they've also backported security fixes where possible from 5.6 back to 5.5, but that's part of their policy, plan, and procedures).
To get these things right takes time. CentOS spent the time up front on 5.6 and 4.9, and both of those were released non-beta before SL released those versions; SL has since released 4.9. Both projects are doing a fantastic job of trying to nail the proverbial blob of gelatin to the wall, and I've hesitated comparing them in any way, simply because I don't want to disparage either project. And the two projects are not in competition. And neither project has a fully visible buildsystem.
In my case, I have essentially three choices: 1.) Use SL 6; 2.) Wait on C6; 3.) Buy RHEL6.
All of the three have costs, visible and hidden. 3 obviously has monetary costs, but both 1 and 2 have time and risk costs, since neither SL nor CentOS will be as fast on updates as choice 3.
There are boxes I'm possibly going with SL, but my servers are likely to remain CentOS, unless and until I can get funding to purchase RHEL (which, since it's a subscription, must be purchased out of opex funding). But I fully realize that if I want a fully supported product in the EL space I'm going to have to pay for it, either with RHEL or Oracle or SuSE. Otherwise I'm going to be happy with what I get, even if that's late.
On 5/11/2011 8:53 AM, Lamar Owen wrote:
In my case, I have essentially three choices: 1.) Use SL 6; 2.) Wait on C6; 3.) Buy RHEL6.
All of the three have costs, visible and hidden. 3 obviously has monetary costs, but both 1 and 2 have time and risk costs, since neither SL nor CentOS will be as fast on updates as choice 3.
There are boxes I'm possibly going with SL, but my servers are likely to remain CentOS, unless and until I can get funding to purchase RHEL (which, since it's a subscription, must be purchased out of opex funding). But I fully realize that if I want a fully supported product in the EL space I'm going to have to pay for it, either with RHEL or Oracle or SuSE.
Individual/personal support is one thing, timely distro updates is something else. With limited experience, I'm beginning to think ubuntu LTS would be a player in the latter space. I've always been a fan of the coordination they have among the additional repositories that is lacking in yum/rpm equivalents and was impressed when my 9.0.4 installs painlessly upgraded themselves to 10.0.4. Admittedly, not as many locally configured apps as on my Centos boxes, but it all still seemed to be working after the major-version over-the-network upgrade.
On Wednesday, May 11, 2011 01:51:08 PM Les Mikesell wrote:
I've always been a fan of the coordination they have among the additional repositories that is lacking in yum/rpm equivalents and was impressed when my 9.0.4 installs painlessly upgraded themselves to 10.0.4.
You must not have many PPA's enabled. And you must not use PostgreSQL, which won't painlessly upgrade on anything.....
Admittedly, not as many locally configured apps as on my Centos boxes, but it all still seemed to be working after the major-version over-the-network upgrade.
I've had the opposite experience with several clients, using Ubuntu as a desktop, not a server. I've had a few issues with servers, too.
Timely updating takes effort; either I pay with money for upstream's binaries or I pay with time for either upstream's source RPMs (which can be delayed) or a rebuild's binaries. Or I pay with transition cost to a different distribution. Those are the choices. TANSTAAFL.
On 5/11/2011 3:18 PM, Lamar Owen wrote:
On Wednesday, May 11, 2011 01:51:08 PM Les Mikesell wrote:
I've always been a fan of the coordination they have among the additional repositories that is lacking in yum/rpm equivalents and was impressed when my 9.0.4 installs painlessly upgraded themselves to 10.0.4.
You must not have many PPA's enabled. And you must not use PostgreSQL, which won't painlessly upgrade on anything.....
Automatically doing the dump/load (and magically finding the space for it) for version changes that need it would be a lot to ask.
Admittedly, not as many locally configured apps as on my Centos boxes, but it all still seemed to be working after the major-version over-the-network upgrade.
I've had the opposite experience with several clients, using Ubuntu as a desktop, not a server. I've had a few issues with servers, too.
With the LTS versions? One of mine was a laptop where centos didn't see the wifi adapter and I had it set up to either dual boot or run under vmware player. And I was surprised that after doing the update under vmware it still came up fine when booted natively and only asked to reconfigure the X setup.
[drifting farther off-topic....]
On Wednesday, May 11, 2011 04:34:49 PM Les Mikesell wrote:
On 5/11/2011 3:18 PM, Lamar Owen wrote:
And you must not use PostgreSQL, which won't painlessly upgrade on anything.....
Automatically doing the dump/load (and magically finding the space for it) for version changes that need it would be a lot to ask.
Yes, I know. Tried.
I've had a few issues with [Ubuntu] servers, too.
With the LTS versions?
Yes.
One upgrade I did from C4 to C5 (with upgradeany) was smoother than the last LTS upgrade I tried. I liken the C5 -> C6 upgrade path as trying to take a Ubuntu LTS 6.06 to a 10.04; which path I tried, and failed, to get working. In one case it was with a Dell laptop that came with Ubuntu from Dell, and that is supported by Dell with Ubuntu. Sound quit (known issue), wireless went funky. One 'accidental' (client-initiated) upgrade from 8.04 to 10.04 lost keyboard and mouse after gdm got control.
And even with Dell's that have RHEL support, I've seen issues with CentOS upgrades; but, then again, neither CentOS nor RHEL ( nor SL) support upgrading.
Upgrades are difficult problems to solve, and at the moment I don't know of any distribution (that claims upgradability) that gets it completely right for all the cases I've tried.
The CentOS path (it's not supported, but if you're brave and know exactly what you're doing there is upgradeany to let you shoot yourself in the foot) I feel is the correct one.
On Thursday, May 12, 2011 04:54 AM, Lamar Owen wrote:
One upgrade I did from C4 to C5 (with upgradeany) was smoother than the last LTS upgrade I tried. I liken the C5 -> C6 upgrade path as trying to take a Ubuntu LTS 6.06 to a 10.04; which path I tried, and failed, to get working. In one case it was with a Dell laptop that came with Ubuntu from Dell, and that is supported by Dell with Ubuntu. Sound quit (known issue), wireless went funky. One 'accidental' (client-initiated) upgrade from 8.04 to 10.04 lost keyboard and mouse after gdm got control.
6.04->10.04? Nah, you are supposed to jump to 8.04 and then to 10.04.
And even with Dell's that have RHEL support, I've seen issues with CentOS upgrades; but, then again, neither CentOS nor RHEL ( nor SL) support upgrading.
Upgrades are difficult problems to solve, and at the moment I don't know of any distribution (that claims upgradability) that gets it completely right for all the cases I've tried.
Not even Debian?
On the OpenSolaris/OpenIndiana side of things, I have not had problems. And you get a complete rollback option too as a bonus.
The CentOS path (it's not supported, but if you're brave and know exactly what you're doing there is upgradeany to let you shoot yourself in the foot) I feel is the correct one.
Right...maybe no longer after you have tasted OpenSolaris/OpenIndiana upgrading
On Thursday, May 12, 2011 06:23:52 AM Christopher Chan wrote:
6.04->10.04? Nah, you are supposed to jump to 8.04 and then to 10.04.
I did 6.06 -> 8.04 -> 10.04, and it broke. Badly.
Upgrades are difficult problems to solve, and at the moment I don't know of any distribution (that claims upgradability) that gets it completely right for all the cases I've tried.
Not even Debian?
The one box I ran Debian on was somewhat unusual, and I lost SMP capability on the box upgrading the one time I did. The box is a DEC AlphaServer 2100 (Sable), and Sable SMP is hard to get these days; the last Debian kernel I know of that supported it was a 2.2 series kernel......
Looking more like I'm going to do at least one, and possibly more, SPARCs on Debian, I'll get a little more experience with it then. I'd rather do CentOS, and be consistent across servers in terms of administration....
On the OpenSolaris/OpenIndiana side of things, I have not had problems. And you get a complete rollback option too as a bonus.
Rollbacks would be good.
The smoothest upgrades of any I've ever done have been on EMC Clariion gear and its FLARE operating environment. But that's controlled hardware, and tightly controlled software, not a general purpose OS, so not directly comparable.
On Thursday, May 12, 2011 11:34 PM, Lamar Owen wrote:
On Thursday, May 12, 2011 06:23:52 AM Christopher Chan wrote:
6.04->10.04? Nah, you are supposed to jump to 8.04 and then to 10.04.
I did 6.06 -> 8.04 -> 10.04, and it broke. Badly.
Ahem. With apt-get dist-upgrade or do-release-upgrade? Things break with apt...do-release-upgrade apparently has some extra logic to not break things...
Upgrades are difficult problems to solve, and at the moment I don't know of any distribution (that claims upgradability) that gets it completely right for all the cases I've tried.
Not even Debian?
The one box I ran Debian on was somewhat unusual, and I lost SMP capability on the box upgrading the one time I did. The box is a DEC AlphaServer 2100 (Sable), and Sable SMP is hard to get these days; the last Debian kernel I know of that supported it was a 2.2 series kernel......
oh. Ah well, I hoped to see some response as I have not ever used Debian yet.
Looking more like I'm going to do at least one, and possibly more, SPARCs on Debian, I'll get a little more experience with it then. I'd rather do CentOS, and be consistent across servers in terms of administration....
Then we can know for sure that Ubuntu really mucked things up and therefore their special upgrade tool.
On the OpenSolaris/OpenIndiana side of things, I have not had problems. And you get a complete rollback option too as a bonus.
Rollbacks would be good.
Maybe after btrfs becomes stable and standard...
On Thursday, May 12, 2011 01:51 AM, Les Mikesell wrote:
On 5/11/2011 8:53 AM, Lamar Owen wrote:
In my case, I have essentially three choices: 1.) Use SL 6; 2.) Wait on C6; 3.) Buy RHEL6.
All of the three have costs, visible and hidden. 3 obviously has monetary costs, but both 1 and 2 have time and risk costs, since neither SL nor CentOS will be as fast on updates as choice 3.
There are boxes I'm possibly going with SL, but my servers are likely to remain CentOS, unless and until I can get funding to purchase RHEL (which, since it's a subscription, must be purchased out of opex funding). But I fully realize that if I want a fully supported product in the EL space I'm going to have to pay for it, either with RHEL or Oracle or SuSE.
Individual/personal support is one thing, timely distro updates is something else. With limited experience, I'm beginning to think ubuntu LTS would be a player in the latter space. I've always been a fan of the coordination they have among the additional repositories that is lacking in yum/rpm equivalents and was impressed when my 9.0.4 installs painlessly upgraded themselves to 10.0.4. Admittedly, not as many locally configured apps as on my Centos boxes, but it all still seemed to be working after the major-version over-the-network upgrade.
Yes, Ubuntu has been quite good on that side of things, 8.04->8.10->9.04->10.4 but having a good dist upgrade process does not cover enough of the other problems you get with Ubuntu 'LTS'. I, for one, will jumping ship at the first opportunity.
Running 1 Hardy server and desktop and 1 Lucid desktop over here.
nothing and apparently today's target date has slipped, and 2) until CentOS admits that there is a problem, nothing will actually change.
Apparently they did admit and it does change: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=31347&forum=...
Mathieu Baudier wrote on 05/11/2011 04:59 PM:
nothing and apparently today's target date has slipped, and 2) until CentOS admits that there is a problem, nothing will actually change.
Apparently they did admit and it does change: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=31347&forum=...
Late breaking news: http://qaweb.dev.centos.org/qa/node/67 http://qaweb.dev.centos.org/qa/node/69
Phil
On 5/12/11, Phil Schaffner Philip.R.Schaffner@nasa.gov wrote:
Apparently they did admit and it does change: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=31347&forum=...
Late breaking news: http://qaweb.dev.centos.org/qa/node/67 http://qaweb.dev.centos.org/qa/node/69
This is really nice and it's good to see that the devs did take all those feedback into consideration and did something to make the process more visible.
As for SL vs CentOS choices, I'd agree both teams did the right thing if only because of how I'm using them. I get to update my existing C5.5s yet at the same time I could use SL6 to begin testing for upcoming deployment as well as troubleshoot potential issues I had with running KVM.
-
Akemi Yagi -
Alain Péan -
Athmane Madjoudj -
aurfalien＠gmail.com -
B.J. McClure -
Benjamin Smith -
Brunner, Brian T. -
centos＠911networks.com -
Christopher Chan -
Chuck Munro -
Craig White -
Craig White -
Dag Wieers -
Dotan Cohen -
Emmanuel Noobadmin -
Gordon Messmer -
John R Pierce -
John R. Dennison -
Johnny Hughes -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Louis Lagendijk -
m.roth＠5-cent.us -
Mark Bradbury -
Mathieu Baudier -
Michel Donais -
Nicolas Thierry-Mieg -
Phil Schaffner -
R - elists -
R P Herrold -
Radu Gheorghiu -
Ray Leventhal -
Rob Kampen -
Ron Blizzard -
Scott Silva -
Stephen Harris -
Steve Clark -
Tom H