[rhelv6-beta-list] RHEL6 finish (~ date)

Thu Oct 7 16:22:59 UTC 2010

What a lot of people don't realize is that there is an RTM date, but it's not public.  I have a hard deadline with some of my official testing with RHEL 6 because of that.  Hold tight, everyone.  It's coming...

Eric Conrad

-----Original Message-----
From: rhelv6-beta-list-bounces at redhat.com [mailto:rhelv6-beta-list-bounces at redhat.com] On Behalf Of Ljubomir Ljubojevic
Sent: Thursday, October 07, 2010 2:07 AM
To: Red Hat Enterprise Linux 6 (Santiago) Beta releases discussion mailing-list
Subject: Re: [rhelv6-beta-list] RHEL6 finish (~ date)

Not having PUBLIC Beta does not mean they do not work with some of their 
   large customers to thoroughly test parts of code. And those that are 
involved in testing all signed NDA.

Those two Betas were mostly published to get initial bugzilla reports, 
and especially hardware related since they had done changes to the 
kernel. And of course to show general direction where they are going, 
and to get response from public and smaller customers.

But once they reproduce initial bugzilla reports they do not exactly 
need us any more to fix them. every rpm spec file of every package has 
detailed dependencies, so anyone can see what other packages will be 
affected if they change a version on one package.

Also, do not forget that most of the packages are from Fedora, and most 
of the bugs are already reported, but authors forced newer version 
instead of fixing known bugs. So I do not see that earth is crumbling 
because they do the work quietly, evading constant criticism of their 
choice and decisions, when they already set their minds how they want to 
proceed. Do not forget that all updates and upgrades they do between 
major releases is also mostly out of sight, so why should major release 
be any different?

If they set release date and then missed it for 2 months, how would you 
react? You would be screaming bloody murder because they failed you, you 
lost money or credibility, etc. But never the less, their product would 
not be out until it is fully finished and they are satisfied with it.

There is one thing you are forgeting. They are a business, not public 
asset. If they choose to discard 10%, or even 30% of their customers so 
they can make 50% more revenue from the large customers, they ARE 
ENTITLED to do so, no matter how it look to us.

And the last thing, but not least, all that testing you are referring to 
is being done, just out of public eyes (in case of Red Hat). And since 
they are not releasing anything new, nothing that was not already 
published and used by other distributions, those who are tracking 
development process of packages they are interested in are already ready 
to implement what ever Red Hat releases, and they most likely already 
tested it on Fedora and are prepared. And since software is not a 
nuclear powerplant, any problems and bugs can be easily corrected 
shortly after the release without destroying half of the planet.

Ljubomir Ljubojevic

John Summerfield wrote:
> Ljubomir Ljubojevic wrote:
>> Do all of you even realize how many bugs Red Hat has to resolve to 
>> move from Fedora sources to bugs free stable product?? If you even 
>> done ANY programming you would understand how complicated is to solve 
>> all the issues popping all the time.
>>
> 
> I don't know, don't care and it's irrelevant.
> 
> I've seen projects involving serious changes of software, the first I 
> recall was when a government dept I worked at as a junior in the 70s 
> converted from one free IBM compiler to another.
> 
> There was evaluation.
> There was a trial conversion of some software.
> There was evaluation of the results.
> There were changes, and prior steps repeated until the results were 
> considered satisfactory.
> 
> Then a real conversion of one application. I don't recall whether any 
> data had to be changed in format, or whether there were interoperability 
> issues across applications, but there could have been.
> 
> It was a lengthy progress, one that had to be done "just so" at each 
> step lest there be lots of unhappy Australians and, as a consequence, 
> unhappy and vengeful politicians.
> 
> If I were working there now, and I knew RHEL RHEL6 was to be released in 
> January, I'd be keeping people available to evaluate the latest version, 
> the real thing, right now. They might be helping ongoing projects, some 
> of them, but they would not be engaging in any Big New Thing at this 
> time. Probably, the core would have been in place for some time, but 
> with the Real Deal on the table, things would step up a notch.
> 
> We'd be evaluating the software's suitability to our needs.
> 
> We'd be evaluating any customisation that might be required.
> 
> We'd be evaluating deployment alternatives, including the platform: 
> IA32? AMD-64? Power? Z-Series?
> 
> We'd be reviewing policies and procedures, especially with regard to any 
> Big New Features, and who gets the new release.
> 
> We'd be revising training requirements and course content.
> 
> We'd be planning and costing new hardware, and maybe running a few 
> pilots, "just to see."
> 
> It might well be that it saw now real action until 6.1, but we'd be 
> looking really closely.
> 
> And if another Linux vendor is more respectful of our need to plan, that 
> might be a serious problem _in our shop_ for RH.
> 
> We can do some of those things with a beta, and that time we might be 
> able to influence the content of final product - for example, by RH 
> changing it's mind about excluding Cyrus Imap - but that possibility 
> means the final product might be significantly different from the beta, 
> and so work done on the beta must be repeated on the final product.
> 
> 
>> If they released unfinished or buggy product, they would lose much more 
> 
> Of course, if the product is buggy, it should be delayed. That happens 
> with lots of software products, and has nothing to do with publishing a 
> target date.
> 
> A target date does not have to be as specific as "20/10/2010," Q4 2010 
> or Q1 2011 is enough to establish in my mind the timeframe for 
> dedicating initial resources and, maybe, acquiring more office space and 
> computer hardware etc.
> 
> With six months to go, or a few months into a beta, RH should have a 
> good handle on the quality of the software and be able to set a target 
> data, say Q1 2010 and then Corporate I might say, Q2 we will be having a 
> Real Good Look at this.
> 
>> than few inpatient customers. At the start of the year there was 
>> prediction that final product should be somewhere around 
>> October-November. Even that time frame gives them one month minimum.
>> But all depends on how many unresolved bugs there are, and how much 
>> time they need to fix them.
> 
> If there is nothing major in the first weeks of a beta, there is very 
> unlikey to be anything major later. If the smaller problems are not 
> numerous early, probably the beta is pretty sound and RH should be able 
> to set a date in the expectation that any problems in the final product, 
> when the media contents are frozen, will be fixable before anyone goes 
> live with it.
> 
> No major customer is going to use it without a Real Good Look. Me, I'm a 
> small-time user of Linux these days, I'd let others use it for a while 
> and then adopt it in the expectation that any major problems I'm likely 
> to see are already found by others and fixed.
> 
> 

_______________________________________________
rhelv6-beta-list mailing list
rhelv6-beta-list at redhat.com
https://www.redhat.com/mailman/listinfo/rhelv6-beta-list