See also the FIXME's and TODO's in the code.


ALPHA PHASE: get some people to test and suggest ideas, while fixing bugs and refactoring
General:
* setup bugtracker/roadmap thingie
* write the ui functions for asking questions etc for both cli and dialog and port all code to use it. 
* find a way to not have to preload libs and stuff, only load them when needed. -> faster start of install program
* test refactored disk code

Specifically:
* lib/blockdevice: autoprepare does not take the last item in 'for fsspec in $STRING; do' (check debug output)
* core/interactive: gui transparancy: interactive autoprepare, package selection
* core/interactive: fix workaround needed for installpkg exitcode
* core/interactive: keymap setting from installer does not go in $target/etc/rc.conf
* lib-ui: don't echo the results, just use the $ANSWER_<foo> variables
* core/base: implement as specified in README
* core/quickinst: figure out what needs to be done and do it.
* find a way to make _cli_ask_checklist still userfriendly for long lists.. maybe we should just propose/ask to use dia if the list is too long
* lib things sometimes call die_error but we go back to the menu.. or something.. i think

BETA PHASE: try to get aif on the (beta) installcd as an experimental, alternative installer.
* involve broader community
* fix everything
* if dhcpd already runs for $reason, the installer will try again @ configure network and
fail.  i tried killall dhcpd, killall -9 dhcpd first but that didn't help:
it can't kill the process or something...
* core/interactive: do not check hard for the dependencies. a user could really know what he's doing or need to reboot after partitioning a disk and
skip that check or something.  Alternatively, maybe just show which steps are done successfully in the main menu

PRODUCTION PHASE: be the primary installer.  deprecate /arch/setup and /arch/quickinst
* fix everything even more
* bribe devs
* core/interactive: when auto-setting up hard disk. show with a bit more detail what is happening (not 'partitioning <disk>' but partitioning, and each FS)
* core/interactive: do pacman -Sy in the background during early phases, to lessen the wait period before selecting packages
* write bash completion thing for aif modules/procedures


SOMEDAY/MAYBE/RANDOM THOUGHTS:
* the quickinst assumes the user did some stuff by himself and does some
after-processing.  Would it be useful to have a procedure that always tells
the user what to do (manually) ? -> ASKDEV
* profiles like 'desktop','server' (~-> package list, configs, disk setup,..) are crossconcerns
compared to procedures (which are about "how" the installation goes:
prescripted, autodetection, interactive,...).
support for profiles could be built in certain procedures), maybe by supplying extra commandline
arguments to the procedure or asking a few questions.
For automatic procedures, a profile could be the fundamental entitiy,
whereas for interactive procedures it could provide some other defaults.
* all dialog windows are equally sized.  noone cares, right?
* we run mkinitcpio twice: one while installing kernel packages, once after
configuring the system (mkinitcpio.conf). can we optimize this?
* core/interactive -> install packages -> dependency cycles with glibc.  not
a problem? -> ASKDEV


WORRIES FOR MAYBE NO GOOD REASON
* base procedure is mostly to serve other procedures.  If we need to do much
work to implement something in the base procedure that we will probably
never use in other procedures, we're doing something wrong.  If that ever
happens (not likely I think), let's rethink what the base procedure should really be.

* instead of every procedure using and overriding the 'base' procedure,
we should maybe have even more flexibilty to take parts from different, specific procedures.
eg: dieter procedure maybe wants to use something interactive. or base procedure wants to do something
from interactive profile (Will this really happen?)
interactive functions maybe dont belong in a procedure?
-> depend_procedure good enough? or do we need more fine-grained dependencies (take function foo from procedure bar from module baz).
for now let's try like this.. -> we can call explicit functions from libraries from modules.. so then just stick it in a lib ->
  lots of stuff can go into lib-ui, making the procedure itself just the
  'execution plan'.. sounds good actually.
problem with this is functions can have the same names (or you need to prepend modulename always, but that's not clean + 'fallback'/overriding doesn't work well anymore. 
alternative -> each lib is a directory, each function in a file, make it possible to source all libs, one lib, or one function from one lib