On Apr 7, 2005 11:59 AM, Mike Hearn <mike@xxxxxxx> wrote: > The definition of what's "core" and what isn't seems pretty vague to me. > There's no need to drop things as more stuff is added, just be more > conservative about adding things! There's no need for FC to have loads of > apps out of the box. It's more important IMHO that it's easy to use and > Just Works. stagnation... thats what you want. Following your logic we could never drop an application, or a library to make room for any new functionality or streamline the system at all. I take it in your world view we should be including a 2.4 and a 2.2 and potentially a 2.0 series kernel for "compatibility" reasons. I mean hell, I know there are some proprietary and open source kernel modules that are well tested and work with 2.4 kernels that havent been ported to the 2.6 kernels yet. Even more so when the 2.4 kernel was dropped outright. If Fedora Core stressed backwards compatibility at the distribution level as strongly as you do, we would never have a 2.6 kernel by default.....stagnation. Your definition of "just works" is different than mine. I do not consider the full space of all previously written codebases when i talk about "just works." Shall I complain about that fact that the old oneko packages from rhl that i relied on no longer work? Or the fact that the absoft fortran compiler doesn't work without compatibility packages being installed? Solve the general forward looking problem of getting compatibility elements from Extras instead of demanding the set of packages in Core remain stagnant and you'll be everyone's hero. > There's no way to do this currently. Then build one. Some compatibility items will be moving to extras. If you feel its too cumbersome to people to interact with Extras to find those compatibility pieces.. build the better interface and mechanisms to help those users out. I think its far far too late in the game to be complaining about how compatibility libraries are treated since they haven't been installed by default up till this point. Its going to be far easier for you or anyone else who thinks compatibility libraries is a priority to engineer a solution that works with Extras than to expect priorities to change. But hey, if you want to try to change the course of a river by shaking your finger at it on the riverbank.. please go right ahead. > Possibly if distributions had > provided a single consistent packaging scheme from the start, > would never have been written. But it didn't work out that way, and now > we have a legacy issue to deal with. Sucks but that's life. Maybe there > are lessons to learn here. Yep and its going to be dealt with by moving some compatibility libraries into Extras and having users install them as needed, instead of installing them by default. So anyone who wants to make it easier to get compatibility elements installed should focus on making it easier to interact with Extras as needed when needed. > Yeah right, just like MacOS X is stagnating. Whatever. That's an obnoxiously silly comparison. MacOS X is a for pay product that encompasses non open software elements which are developed in a highly closed process. apples to oranges comparison. Fedora's long term development priorities are publicly available as a guidance for this project, MacOS X's are not. And I dare say, as an individual you have far more potential to impact what goes on in fedora through your individual contributions to any specific piece of distribution than you have with the direction of MacOS X development. -jef
