Havoc Pennington wrote:
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)?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.
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
