FC4 slimfast slimfest

[Michael Favia]

Elliot Lee wrote:

>Hi all,
>
>Here's a heads up that we need to get rid of about 300M of packages to
>make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
>xemacs, cfengine, and all the games are leading candidates. We also may
>try to start removing stuff from Core in hopes that it will appear in
>Extras if someone cares about it.
>
>Nothing is set in stone, but if you want to write in favor of keeping
>something, you'll have to suggest something else of equal or greater size
>to axe instead.
>
>You can view the list of new packages since FC3 (sorted by package size)  
>at http://people.redhat.com/sopwith/new-packages.txt
>
>FYI,
>-- Elliot
>
>  
>

*Abridged Version*
Developers can be expected to work a little harder to establish a 
working environment and have the knowledge skills and abilities to make 
that happen. Consumers neither know how nor want to know how to work the 
magic that makes everything the way they like it they would just like it 
done for them. Towards this goals improve the end user experience so 
that the developers continue to develop for a growing audience instead 
of a shrinking one. I don't know if this is possible on short niotice 
for FC4 but may be worth review for architecting fc5. Thank you and good 
luck.

*Unabridged Version *
this seems like a discussion that is held frequently and is always 
contentious. Instead of arguing the acceptability and merit of a 
particular package perhaps our time is better spent working up a rough 
framework of what our *specifications* are first. I think we are 
designing the perfect solution to the indescribable problem here. I 
would like to propose the following for consideration:

New/Average consumers represent the least experienced and the largest 
growth segment for Fedora.  They are most fickle in their adoption and 
most skeptical in their approach. Developers, server administrators and 
every other use case is commited to fedora for more substantial reasons 
in most cases (development model, release cycles, etc) and have the 
knowledge, skills and ability to take the time and perform and extra 
step to transform the default working environment into their desired mode.

* New users that have little or no Linux experience seem to be 
interested in Fedora at an increasing rate. I argue that they will 
choose to adopt fedora if we make the dfeault environment as smooth as 
possible for these users who have no knowledge and arguably shoudl 
require no knowledge of repos and configuration files for things to Just 
Work.

* Developers are basically knowledgable and communicative. If something 
is not as we expected we ask each other on IRC or in a mailing list or 
forum. We know how to configure repos and upgrade and install new 
packages. If we don't it can at least be argued that we should be 
able/required to learn.

* Fedora adoption of both consumers and developers is a good thin and 
there are many more consumers than there are developers out there.

* Fedora relies on developers and will do so at an increasing rate with 
the launch of fedora-extras

No I'm not arguing to purposefully make life more difficult for 
developers. Instead i am arguing for the "greater good" created by the 
developers ease of overcoming simple deviations and how detrimental 
those same obstacles would be to the average/new user. To that end i am 
suggesting that the user runtime environments (including a java runtime 
that is differentiated from eclipse if they are currently bundled for 
some odd reason), default desktop , and default applications (office, 
web, file, mail, message) should take priority on the first CD['s] 
(including required desktop libs to satisfy default apps). Once the 
requirements for that are met than either place the alternatives on the 
next/remaining cd's followed by the development tools or vice versa 
depending on which user segment you think will benefit greater.

-mf