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.