From: Alexei_Roudnev (Alexei_Roudnev_at_exigengroup.com)
Date: Wed Apr 11 2007 - 23:55:16 CEST
Message-ID: <1b0101c77c84$16c958d0$6f31a8c0@sjc.exigengroup.com> From: "Alexei_Roudnev" <Alexei_Roudnev@exigengroup.com> Date: Wed, 11 Apr 2007 14:55:16 -0700 Subject: Re: [suse-sles-e] SLES10 SP1 in public beta. My congratulations to SuSe team!
Or to change in README (caveats).
On the other hand, if you suddenly discover that your SP1 panic on new HP
Proliant server (where it is expected to work well, for example), then you
can delay it or at least mark (just again) in caveats (for HP proliant XXX,
wait for the upgrade).
I don't know how RHEL did with RHEL5, but it was available in public beta
for a very loing time, and it resulted in really good set of different
products _already_ available for it and it a very good starting quality of
the system. I expect the same from Novell.
> yep ... it just seems more like what an OSS company would do>
> Probably it wasn't clear what I meant: If you release a beta version,
> the expectation you set is that feedback will lead to changes in the
> system.
Good beta programm can release resources and not delpete them. Esp. because
Beta testers do some work instead of QA team and sometimes can propose
solutions for the problems.
In the worst case scenario (Beta is on RC stage only) you at least got less
'support' calls because you already have 10 - 20 _wellknown problems_ in
release notes (caveats) so that people can avoid non-working conditions and
configurations.
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Thu Apr 12 2007 - 02:01:46 CEST