RHN Updates

[Jef Spaleta]

Matthew Winter wrote:
>I would like to see RedHat enhance the RHN into a subscription based
>Package Install / Update / Search system.

I think redhat is going to have to enhance rhn in someways...for the
idea of the RHL-project to take off...where you really can get 3rd party
addons from something like fedora or freshrpms (or horrors of horrors
proprietary addons) for the rhl releases. How exactly the full catelog
of rhl project packages and related 3rd party addons like fedora will be
accessible is probably still very much an open development question. But
if the idea of RHL as project is really going to blossom, then how the
tools in the rhl releases interacts with community contributed packages
is going to have to be expanded for sure.

>I for one would subscribe to such a service, to guarentee that packages
>have been properly compiled for a specific release of RHL, and tested.

Now this is the problem...redhat can't really garuntee that additional
stuff is going to be able to work. For example...we as experienced users
trust freshrpms and fedora to a great extent to provide quality add-on
packages. But the problem comes with poeple want redhat to 'garuntee'
that such addon packages will work. Redhat doesn't have the manhours to
garuntee and test the full range of what could potentially be considered
rhl community contributed packages. One of the points of switching to
this project idea, is to try to address this problem, by shifting some
of the burden of package maintance to the community's shoulders. If we
are going to ask redhat to garuntee that packages work...then redhat is
stuck providing a base number of packages that they have the manhours to
support. But if we no longer expect redhat to garuntee every package we
get from rhn...then that opens up the idea of 'partner channel' like a
channel for fedora or freshrpms. RedHat can't garuntee anything from a
fedora channel will definitely work...but if Redhat can tie the
community developers more directly into the rhl development process and
the rhn process...then we as users can work with the fedora or freshrpms
packagers or whomever to provide something close to that garuntee you
want. 

But i think there is a lot of ground work that needs to be laid before
we can talk seriously about rhn offering 'partner channels.' A lot of
the mechanics of how community developers from outside of redhat can
interact with the rhl development process..a lot of new policy
groundwork here...some of it has been touch on here in this list
already, and I'd imagine there other rhl lists are discussing this in
more detail. But i would say that one of the longterm goals of rhl ehas
got to be easy to use support throughout all the rhl tools (up2date and
r-c-packages included...maybe even the installer) to  get access to a
whole ecosystem of community support packages that go beyond the base
distro that redhat has the manhours to support directly.   A serious
desktop product will have to have easy to use access to a wealth
additional software that redhat can't garuntee directly...but software
provided from 3rd parties that we has a community of users have grown to
trust.

>I also think that the software should allow you to choose from Stable
>and Test releases. Allowing a user to decide what they want to install.

That im not so sure about....that making it too easy for people who
don't know better to do things they think should work better but don't.
People equate an increase in version number with 'better' far too much
for their own good. Did you miss the thread about the removal of
'expert' mode from the installer? 

I don't think its wise to encourage the average user to run testing
software as an option to stable software...i think a clear distinction
between what is a stable release and what is in testing is very
important to make sure people don't idly start chewing on experimental
packages.  If the goals of the point and click tools is to provide a set
of tools the average users can rely on to give them trusted updates.
Given those same users the option to pull test packages with those same
convience tools...undermines the point of the tools...to keep things
running smoothly for the average user.  Out of the total number of
redhat users out there, what percentage really should be consuming test
packages? Should this project be designing convience tools around the
needs of the testers? Or should this project focus on the needs of the
stable package users?  I think one of the largest needs of a stable
system is to make sure the easy to use tools...aren't so easy to use,
that it makes it easy to fubar yer own system. That's what commandline
tools are for.

-jef"sadly, my crystal ball comes with a NDA, so I can't tell you what i
see happening with RHL 2 years from now"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/20030803/3d18f660/attachment.sig>