only FYI:
http://osnews.com/story/24760/Red_Hat_Enterprise_Linux_6_1_Released
centos-bounces@centos.org wrote:
On Thu, 19 May 2011, carlopmart wrote:
Red_Hat_Enterprise_Linux_6_1_Released
and look at all the anaconda related, and other fixes, that should have been in a dot zero release ... gee
-- Russ herrold
Which means, that RHEL6.0 should have just now come out today; the release called 6.0 was a teaser and a beta of the release called 6.1 which should have been called 6.0!
So when is CentOS6.1 coming out? (I can't help it, I just can't help it).
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 Thu, 19 May 2011, Brunner, Brian T. wrote:
herrold earlier: and look at all the anaconda related, and other fixes, that should have been in a dot zero release ... gee
Which means, that RHEL6.0 should have just now come out today; the release called 6.0 was a teaser and a beta of the release called 6.1 which should have been called 6.0!
There is an old piece of wisdom in IT to avoid the public 'dot zero' products so that some-one else gets to be the advance guard scout (you know, the one who staggers back to base camp, festooned wth arrows in him)
even if a vendor names its initial product 2.1, or 3.0.3, it is still a 'dot zero' until eager and inadvertent public release (and perhaps unknowing) 'gamma testers' ('They CAN'T BE 'beta' testers -- we _did_ a beta') get fried a few times, a la Dr Bruce Banner and his Gamma ray accident
-- Russ herrold
On 19.5.2011 15:56, R P Herrold wrote:
There is an old piece of wisdom in IT to avoid the public 'dot zero' products so that some-one else gets to be the advance guard scout (you know, the one who staggers back to base camp, festooned wth arrows in him)
Oh Lord! If everyone would avoid 'dot.zero' products then no bugs would be discovered and no 'dot.one' product would be released. You basically tell me if I cant resist and try I am an idiot and are beta testing for you. So I am reacting and try to resist using 'dot.zero' hoping that you will do the beta tests for me instead. Leading to stagnation. Possibly it works out (for one of the two of us), but I would not call it wisdom. There is another "piece of wisdom" that says "Never change a running system", which forbids updates anyway.
(possible duplicate -- the first post had some mal-formed headers that the MailMan should have rejected)
On Thu, 19 May 2011, Markus Falb wrote:
Oh Lord! If everyone would avoid 'dot.zero' products then no bugs would be discovered and no 'dot.one' product would be released. You basically tell me if I cant resist and try I am an idiot and are beta testing for you. So I am reacting and try to resist using 'dot.zero' hoping that you will do the beta tests for me instead.
Please note that I have publicly confesssed here to running a local private testing build of the upstream's 6.0 sources, several times, and have the arrow collection in my pysche to show for it [this shows I am a glutton for punishment]
But I am NOT running it production
And I am not afraid of the planet running out of 'idiots' who will test -- the Lord seems to have created an endless supply of such, some of whom have been howling on the mailing lists, asking to have arrows shot at them by the CentOS team
-- Russ herrold
On 5/19/2011 9:40 AM, Markus Falb wrote:
There is an old piece of wisdom in IT to avoid the public 'dot zero' products so that some-one else gets to be the advance guard scout (you know, the one who staggers back to base camp, festooned wth arrows in him)
Oh Lord! If everyone would avoid 'dot.zero' products then no bugs would be discovered and no 'dot.one' product would be released. You basically tell me if I cant resist and try I am an idiot and are beta testing for you.
Everyone expected this from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
On Thu, 19 May 2011, Les Mikesell wrote:
Everyone expected this from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
You'll have to direct questions of the upstream's intent to the upstream
-- Russ herrold
Les wrote:
Everyone expected this from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
not really sure what you are saying Les...
what are you saying?
are you talking about Red Hat internal processes ?
it is a very profitable publically traded corporate structure with employees and products...
what dont you understand about that?
- rh
On 5/19/2011 10:15 AM, R - elists wrote:
Les wrote:
Everyone expected this from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
not really sure what you are saying Les...
what are you saying?
I'm saying that Red Hat got to be a big company because of the community involvement after they shipped buggy code that would boot on most PCs of the era and some (probably small)percentage of the users were able to contribute fixes and bug reports.
are you talking about Red Hat internal processes ?
I'm talking about the change in that process where the community is only involved in Fedora, and the expectation that the closed work on EL was supposed to make it less buggy when shipped.
it is a very profitable publically traded corporate structure with employees and products...
Yes, it is clear why closing access is a benefit to them. Not so much to anyone else.
what dont you understand about that?
Did I misunderstand the comment about X.0 releases? I took it to mean that the closed work didn't really product a perfect result.
On Thursday, May 19, 2011 10:59:45 AM Les Mikesell wrote:
Everyone expected [dot-zero bugfest] from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
Sounds like a question for rhelv6-list@redhat.com
Les Mikesell wrote:
On 5/19/2011 9:40 AM, Markus Falb wrote:
There is an old piece of wisdom in IT to avoid the public 'dot zero' products so that some-one else gets to be the advance guard scout (you know, the one who staggers back to base camp, festooned wth arrows in him)
Oh Lord! If everyone would avoid 'dot.zero' products then no bugs would be discovered and no 'dot.one' product would be released. You basically tell me if I cant resist and try I am an idiot and are beta testing for you.
Everyone expected this from Red Hat before the 'EL' versions when publishing a free CD of community work was the way QA was done. (And if you've forgotten, go dig through some changelogs of that era to see just how bad things were and how much we gained from that process). But wasn't closing the process and letting 'experts' do that before shipping supposed to have improved things?
If you consider how much bugs there are in Fedora in last years, this is not to bad either. Considering the number of errors, maybe waiting for CentOS 6.0 had it's benefits, even none of us likes such a long wait. I started holding my breath when RHEL 6 Beta was released, and my face is not blue any more but totally black :-)
Ljubomir
R P Herrold wrote:
On Thu, 19 May 2011, Ljubomir Ljubojevic wrote:
started holding my breath when RHEL 6 Beta was released, and my face is not blue any more but totally black :-)
Yowzer -- Zombies!!!
The CDC can help with that.... http://www.neatorama.com/2011/05/18/official-us-government-website-provides-advice-on-survival-during-a-zombie-apocalypse/
mark
no, the saying is...
if it aint broken, dont fix it !
especially on weekends, monday, or friday
;->
that is why everyone should have a small or large lab for testing and rollout...
- rh
Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
On Thu, 19 May 2011, carlopmart wrote:
Red_Hat_Enterprise_Linux_6_1_Released
and look at all the anaconda related, and other fixes, that should have been in a dot zero release ... gee
Which means, that RHEL6.0 should have just now come out today; the release called 6.0 was a teaser and a beta of the release called 6.1 which should have been called 6.0!
So when is CentOS6.1 coming out? (I can't help it, I just can't help it).
<Rolls up newspaper and whacks Brian sharply on the snout>
mark "mind your manners!"
--On Thursday, May 19, 2011 10:22 AM -0400 R P Herrold herrold@owlriver.com wrote:
and look at all the anaconda related, and other fixes, that should have been in a dot zero release ... gee
At the risk of opening another can of worms:
If you deferred releasing a 6.0 and instead immediately started working on 6.1, how much additional time would that add to getting 6.1 out? I'm not so much asking for an actual estimate, as I am whether it would be easier just to go directly to 6.1 if it fixes any issues that make building the release easier.
On 05/20/2011 07:46 AM, Kenneth Porter wrote:
--On Thursday, May 19, 2011 10:22 AM -0400 R P Herrold herrold@owlriver.com wrote:
and look at all the anaconda related, and other fixes, that should have been in a dot zero release ... gee
At the risk of opening another can of worms:
If you deferred releasing a 6.0 and instead immediately started working on 6.1, how much additional time would that add to getting 6.1 out? I'm not so much asking for an actual estimate, as I am whether it would be easier just to go directly to 6.1 if it fixes any issues that make building the release easier.
We basically need to get an almost fully functional version of 6.0 working anyway. In order to build the 6.1 packages, we need a fully up to date 6.0 tree to use for the build roots.
The only thing that might speed up the 6.1 release process is to skip the anaconda generated ISOs for 6.0. But, in reality we are fairly close on 6.0 at this point, we may as well release it since we need a tree to build on anyway.
-
Brunner, Brian T. -
carlopmart -
Johnny Hughes -
Kenneth Porter -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Markus Falb -
R - elists -
R P Herrold