RHN Updates

[Jef Spaleta]

Gilles J. Seguin wrote, somewhere in the digest:
>The third item require that peoples with a minimum of training
>be able to install and play with a package.

Yes i understand that submitting useful bugreports doesnt take much in
the way of training...neither does breaking a working system, without
fully understanding the consquences of your actions :->

But I'm more concerned about getting into a situation where the
convience tools...the point and click tools like up2date...start getting
features where people can easily install 'testing' packages on top of
full releases..without having to stop and think about what they are
doing...when they have no intention of actually being a part of the
testing process...and don't have a clue about how to recover if the
testing packags are broken.

I firmly believe a large segment of the user population do not read
documentation before they start pointing and clicking their way through
applications...and a lot of those people are download junkies....there
is a kneejerk reaction to upgrade when a version number higher than what
you have installed is available. You give people some form of easy to
use 'expert' or 'testing' options to up2date and rhn, and a lot of them
will assume they know enough to use these option and will just point and
click their way to a broken/insecure system ..without making any attempt
to understand what 'testing' really means. I think this ultimately
undermines the service rhn provides...but that's my opinion, luckily I
don't have to make business decisions for Red Hat...how i balance the
trade-offs in service rhn provides is thankfully not what people base a
business model on.

This is one of those trade-off things. If you give rhn options to
provide 'testing' packages on top of a normal release, sure this will be
marginally more convient for the people who want help test packages. But
it also provides a mechanism where less technically competent people can
easily install things that break their systems..and these less
technically competent people, might not understand their system's deep
dark underbelly(commandline) well enough to make a recovery attempt if
things break. Its a convience..versus risk tradeoff. I'm inclined to
think that if you are running testing packages...you should be familiar
enough with the commandline to use rpm/yum/apt at the commandline to
download testing packages, so that if things break down, you are
competent enough to make a stab at fixing things.  Its not in everyone's
best interest to run testing packages, and i think having testing
packages for full releases in rhn would end up encouraging people to do
things, not in their best interest...degrading the trust and service rhn
provides to a large segment of the rhn userbase.

Its one think to provide a clear beta release with a separate isoset
with a seperate rhn beta channel. Providing 'testing' updates in rhn as
an options for a full release...is something different..and makes it
really easy for people to get into situations where they screw up
running systems just because they wanted the latest and greatest version
number.   


-jef"rolling releases are to avoided...on pain of death"spaleta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030805/159aba89/attachment.sig>