Wild and crazy times for the development tree

[Jeremy Katz]

On Mon, 2006-03-20 at 21:15 +0000, Paul F. Johnson wrote:
> > But let's get a clear roadmap down this time, what features are
> > essential for the next cycle?
> 
> A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> large reduction in the overall memory overhead. I know FC is fantastic,
> but given you need 128Mb for a text only version and 512Mb for a desktop
> environment, it's becoming hard to justify to the powers that be that
> using Linux over WinXP is that good an option.

We're actually probably significantly better than FC4 on memory overhead
for the most part.  Installation is a little higher overhead this time
around and most of the reason for bumping the recommendation.  

> Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
> - Debian (sorry for swearing on this list) is a whole lot smaller than
> FC in terms of memory again.

It all depends on what you're defining as your desktop environment.  We
could do fvwm instead, but I really don't think that's what most people
want.

> I think it was suggested that ISOs are made of FE. It may be time to do
> this, but with quite a lot from FC moved to it. For example, gcc-gnat,
> gfortran, objc and anything *not* mono/mcs (in other words, beagle,
> fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
> gnat. The OOo language packs should also be moved out - just keep in
> french, german, spanish and any big userbases.

The problem is that a lot of this is split over src.rpms that *must* be
in Core.  And right now, there's no way to do that split.  Given where
some things stand, I think that we can start thinking about tools to
make it easier for building CD sets and shadow repositories in the FC6
timeframe and then start really rethinking a release after that.

> The same applies to Qt and KDE - quite a lot of the material in there
> should be in extras, Qt (standard + devel) and some of the kde system
> should be in Core. We also have a number of different database systems
> in Core. Could a case not be made for trimming it down to MySQL and
> postgresql with the rest again going to FE?

We don't really ship any substantial (ie, non-embedded) databases other
than mysql and postgresql that I know of.  And changing the embedded
database for a piece of software isn't a trivial thing.

Jeremy