installer final touches matters

[Kevin Kofler]

Muayyad AlSadi wrote:
> the fedora's new installer got many innovative features
> 
> but it's missing many critical easy to fix final touches from user
> experiance point of view

And worse, it's got a known bug list longer than Window$ 95's!

The way this was handled is really a catastrophe and should not be allowed 
ever again! In particular:
* DO NOT REWRITE code! It will ALWAYS break things!
* If you do major changes, you MUST do them in a branch! Rawhide is NOT a 
place to do experimental changes like these!
* You MUST honor the schedule of Fedora! Otherwise, the old version MUST be 
used! (And it MUST be shippable, see above!) Slippage like the one we had in 
F18 is NOT acceptable!
* Your new version MUST be COMPLETE when it's merged into Rawhide! And even 
more so when it's actually shipped! It is plain unacceptable that many 
things users expect to just work are simply "not implemented yet"! (Again, 
this is what branches are for!)

As long as FESCo is not willing or able to enforce those common-sense rules 
on Anaconda developers, we will always have releases which suck, right in 
the very first component our new users get to see.

In addition, Anaconda's memory use has been skyrocketing for several 
releases, and the design changes in F18 have done nothing to address that 
issue. (In fact, they likely made it worse.) Anaconda has a years-long 
record of replacing size-optimized implementations of important 
functionality targeted specifically at Anaconda by "let's just import the 
installed distro's heavyweight implementation", all in the name of "code 
reuse". Piece after piece, most of Anaconda's functionality was rewritten to 
be based on some heavy library, adding megabytes of required RAM each time. 
The result is that Anaconda's memory requirements have increased by an order 
of magnitude since Fedora's inception, and even 2 orders of magnitude 
compared to older RHL releases.

        Kevin Kofler