Toshio, Perhaps you could read the strawman document that I sent to this list last week. I proposed many answers to the questions you raised. Whether or not they are the right answers needs to be discussed, but until we start criticizing a common framework, we'll all keep reinventing the wheel. Perhaps my email was lost because it was part of a larger thread, so I will re-post under a new thread header. M On Sat, 2004-07-24 at 21:57, Toshio wrote: > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > > debate the possibility of such an action and which programs to move in > > that is the case. > > I'm not in favour of discussing what packages to move out of Core at > this time. But "debating the possibility" *and the desirability* sounds > good provided we derive something concrete from it rather than just > another "good idea gets bandied about and found to have holes that no > one ever bothers to address" session. In particular: let's discuss what > infrastructure and policy clarifications are prerequisites to changing > how comprehensive core is. > > Reasoning: I think it might be possible to weed out a package here and a > package there that can be removed or replaced in Core but I don't think > we're currently ready to cut up the distro into CD sized pieces and let > users download each one at will. Many people have touched on the fact > that this is an issue, but I haven't seen an attempt to spell out the > length and breadth of the problem. > > Here's my attempt to add something valuable to the discussion: > > * Fedora Extras > - We need to have Extras officially "in place" (so we can see how it > interacts with Core.) > - Define Red Hat's relationship: > + Oversight. Red Hat pretty much controls Core. What about Extras? > + Resources. Red Hat is committing hardware to Core (and I believe > Extras) but what about personnel? Does movement of packages from Core > to Extras mean the packaging burden shifts to community support or will > RH pay employees to maintain packages in Extras? > > * Distribution of add-on releases > - Since using FC, I've realized the time-saving benefits of > bittorrent. If I have to download 500MB-1GB of packages to replace what > was left out of Core, will I be able to get it as fast? > - How are we going to choose what should be on Extras CDs? If we > think it's hard choosing what should be in and what should be out of > Core right now, how are we going to feel about choosing what should be > in an Extra Server CD? An Extra Desktop CD? A KDE CD? Can there be > overlap? > - What type of schedule are we going to propose for Extras CDs? > - Will Extras be rebuilt along with Core _before_ a FC release (so > Extras software can be updated simultaneously.) > - When installing Core, will loading of Extras/3rd party CDs be > supported? > - What technical hurdles can stop packages from being upgraded without > help from anaconda (and therefore need to remain in Core)? > > * Packages already in Core and those in RHEL: > - How will we deal with dependencies that are unmet by a smaller Core? > - Red Hat "justifies" Core as a testing ground for RHEL. How does > this requirement affect what can be moved out of Core into Extras? > > * Direction of the Distro: > - Maybe it's just my impression. Maybe it's Linus's statement that > Linux needs more applications. I get the feeling one goal of all > distros is the concept of "more." If we're going to consciously try to > reduce the size of Core, are we going to still claim "more" by touting > Extras? Are we going to replace it with something better? (I'm > personally voting for "Delightful" :-) > > * Numerous other things I've missed -- I'm depending on Jef"my memory is > like an elephant's and my insight is as keen as a taoist monk's"Spaleta > to flesh things out. (Isn't it nice to have a middle name that makes > people think of you as an authority figure?) > > Personally, I'm a fan of increasing the distro size. However, the idea > that was passed around of having a microFedora with Core built > _transparently_ on top and Extras releases _transparently_ on top of > that strikes me as a goal that would bring the most change for the least > dissatisfaction (assuming that dissatisfaction is a sliding scale from > "I can live with it" to "I'm going to run that other OS from now on!" > rather than a boolean value.) If it's attainable (politically as well > as technically) let's shoot for that. I think answers to these > questions are some of the necessary precursors to getting there. > > -Toshio
