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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
