> 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
--
_______S________U________B________L________I________M________E_______
t o s h i o + t i k i - l o u n g e . c o m
GA->ME 1999
Attachment:
signature.asc
Description: This is a digitally signed message part
