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
* setup bugtracker/roadmap thingie
* check everywhere that if users cancels something, we return 1, empty string behavior etc
* core/interactive: fix workaround needed for installpkg exitcode
* core/interactive: keymap and timezone settings from installer dan't not go in $target/etc/rc.conf
* dm_crypt unlock at boot is in qwerty.
* after unlocking dm_crypt, FS check fails (reiserfs, must try other)
* 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
* automatically configure grub for dm_crypt and lvm


BETA PHASE: try to get aif on the (beta) installcd as an experimental, alternative installer.
* find a way to not have to preload libs and stuff, only load them when needed. -> faster start of install program
* 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
* support maybe ntp to set clock
* auto-configure mkinitcpio.conf for dm_crypt and lvm

PRODUCTION PHASE: be the primary installer.  deprecate /arch/setup and /arch/quickinst
* fix everything even more
* bribe devs
* 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
* add dmraid/mdadm support -> patches welcome.  i don't care about this. 

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