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@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv6-beta-list
