RHN Updates

[Gilles J. Seguin]

Jef Spaleta wrote:
> 
> 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?

In the idea that, see reference below, at the level of the 
distribution, bugzilla is the best mechanism we know for allowing
management of anything related to package.

My understanding is:
- The most valuable resource are developpers
- QA(quality analysis) is a tough human related job.
  Consequently difficult to train.
- bugzilla, by nature, requires people to able to fill a report.

The third item require that peoples with a minimum of training
be able to install and play with a package.

> 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.

What is implicitly said here is that some packages have big
impact on the entire system.  Let says, kernel and glibc.
We need to educate user, what make sense and what is not.
That means they have an impact on the system reliability or
consistancy(state).

Third party sofware are generally of no consequence.
If they crash, it is what we want to know.

> 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? 

>From my point of view, higher is the better.

> Should this project be designing convience tools around the
> needs of the testers?

What are the need of the tester ?
What I would like to see in rawhide is the package test.
Example:
- library-test-newversion must appears days before the
  application that use them.
- It is much easier to develop a test case.  How many time
  have not report a problem because saying "it does not work"
  is of no used in bugzilla.

> Or should this project focus on the needs of the
> stable package users?

This goal is implicitely meet if the goal of previous group is met

> 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.

<http://www.redhat.com/archives/rhl-beta-list/2003-July/msg01097.html>

> -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

For sure, problems will get harder and harder to resolve.
The easy ones have disappear.