Anaconda: good work!

[Jeremy Katz]

On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> First impression: anaconda really rocks! This is a
> very solid, pleasant installer.

Thanks -- always nice to see people not just flaming us :-P

> I do have a few _minor_ points that I think would
> make it a bit nicer to use:
>   * PASS/FAIL color coding
>     When testing disks, there's nothing in the way
>     of visual feedback between the PASS/FAIL screens
>     (I haven't actually seen the FAIL screen :), but
>     I assume it hasn't changed since FC4)
>     This is a screen that I tend to dismiss quickly,
>     and I'm left with that nagging feeling that I didn't
>     read the text right. A green/red background just for
>     the word PASS/FAIL will help immensely.

I think there's actually a bug about this.  Doing it in newt isn't as
easy as one would hope, though :-/  I do agree that making the
difference between pass and fail more obvious is probably a good idea.

>   * The text based boot is ugly
>     Rather minor point, but a graphical initial boot 
>     would make for a less intimidating experience in
>     this otherwise flawless graphical installer.

As others have said, the problem is that we're relatively space
constrained here.  rhgb ends up requiring X at which point we're using
way more space than we currently do.  Any other solution ends up
basically being the realm of kernel patches that aren't upstream

>   * Disk change indicators
>     Not sure it's worth the trouble, but it would be
>     really nice if we got some ticks along the progress
>     bar on when we can expect we will need to change
>     the CDs. This would also tell someone which CDs are
>     needed. It would help people a lot to manage their
>     time during installs.

This comes up from time to time, I'm just not fully convinced of how
useful it is.  One thing that we really probably need to look at for FC6
is revisiting the time remaining algorithm.  It seems that every few
releases we need to go in and really prod at it to make it more
accurate.  One of the not measurable things which has a pretty big
impact ends up being the various cache generators run as %post
scriptlets of packages.

>   * Links don't work in Release Notes
>     Rather frustrating, considering the size of the doc.
>     Links within the document should work, if they
>     look like regular links (color, cursor)

Yeah.  We didn't have HTML release notes until late in the game.  At
that point, I noticed but it was a bit risky to be going and making the
necessary changes to have them work.

>   * External links in Release Notes are confusing
>     These can't possibly work, it would be nice if we
>     can disable them to avoid confusion.

Hrm.  Not sure how to handle this.  They could conceivably work in
network installs, but are almost certainly a bad idea.  Maybe the way to
do this is to do some processing on the release notes file before we
feed it to the viewer

>   * Space does not page down in Release Notes
>     I am so used to use space to page down in viewers,
>     I really miss it when I can not do so.

This seems like it should be easy enough to implement

>   * Release Notes too big?
>     I found them to be too big/verbose, especially for
>     a light read during install. But maybe it's just me.

Yep, the Docs project has rocked at getting lots of content.  This has
the downside of there being lots of content.  Double-edged sword...

Jeremy