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