reducing distribution CD count

Michael Favia michael.favia at insitesinc.com
Fri Feb 25 03:47:14 UTC 2005


Havoc Pennington wrote:

>I think it's accurate that Red Hat would like to be maintaining fewer
>packages and focusing more on the basics, but at the same time I don't
>know why people are so terrified of that. It will probably make both the
>basics and the non-basics higher quality to do this since there's more
>focus on each one.
>
>At the same time I doubt the core/extras line will end up being Red Hat
>maintenance vs. external maintenance. I think we're heading toward some
>other definition of core vs. extras. My personal preference leans toward
>saying core is roughly the union of default install classes, but I'm
>sure others have thought about it more.
>  
>
I am of the same persuasion. And i agree completely on the 
simplification of the distro and the focus on fewer "default" packages 
because it means the half-life of innovation will decrease dramatically 
with respect to the "normal users experience". I harbor no fears of 
abondonment and i think others could be placated as well but believe 
many are complaining because of the dirth of information available on 
future plans (possibly because they arent known). As we all know 
uncertainty shakes even steely-eyed missle men hesitent. Many of the 
political battles (kde/gnome, exim/sendmail, etc) shoudl be put to rest 
(finally) when this time comes. I think that "core" as a non duplicating 
set of functionalites is a great idea that decreases the installation 
media requirement, bandwidth and overall workload per innovative step. 
The rest can and should be maintained by the community with RH picking 
up the ball where it is in its best interest (e.g. angel coding, 
switching or providing compatability). The key to making this work 
without alienating a contigent userbase will be the simplicity of 
selecting and installing non-default (core) packages on installation and 
after the fact (via network and "extras" cd's). Will the slip of test1 
have any effect on the possible availability of a multirepo anaconda up 
to such a task (fully realizing that there are other hurdles like 
"extras" installation cd creation)?

Assuming the same amount of resources are comitted to the project a 
slimmer, more agile, faster moving fedora core will be the result of 
moving in this direction and i for one welcome it. Thanks for the 
feedback on the earlier post.
-michael




More information about the fedora-devel-list mailing list