summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorDieter Plaetinck <dieter@plaetinck.be>2008-11-10 17:09:17 +0100
committerDieter Plaetinck <dieter@plaetinck.be>2008-11-10 17:09:17 +0100
commit03076dad4bd7bbffdee05af4133af052a73a8c9b (patch)
tree113cc61277955913e583bf7e86c357d8544a5c37 /TODO
parent08c729463d520125bdaed26b319ee0ad7095063d (diff)
big todo overhaul: rethought some stuff + laid out roadmap
Diffstat (limited to 'TODO')
-rw-r--r--TODO102
1 files changed, 61 insertions, 41 deletions
diff --git a/TODO b/TODO
index cd6a4d6..ef0503e 100644
--- a/TODO
+++ b/TODO
@@ -1,47 +1,67 @@
-* fix the big bug that causes no workers to be executed anymore
+See also the FIXME's and TODO's in the code.
+
+
+ALPHA PHASE: get it sort of reasonably working
+General:
* go over ALL files and check all function/executable calls are to existing
things (eg no dirty leftovers for functions that have been renamed)
* same for variables
-* make interactive procedure working well.
-* base procedure wordt implementatie van alles wat auto gaat uit setup script, other steps warning 'not implemented'
-* in elke phase een lege worker die te overriden valt zoda we geen phases
- moeten overriden
* fix to use $var_UI_TYPE where needed
* write the ui functions for asking questions etc for both cli and dialog and port all code to use it.
-* instead of using the 'base' procedure and letting other procedures override,
- we should have even more flexibilty to take parts from different procedures.
- eg dieter procedure maybe wants to use something interactive. or base
- procedure wants to do something interactive. 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
-* base procedure idea: it should just tell you what to do? -> less
- implementation work in base procedure, more in other procedures...
-* fix crossconcerns: procedures are about _how_ (autodetection, asking user,...)
- what about _what_ (desktop,server) --> 'mode'? 'profile'? procedures
- define for themselves how much they care about the 'profile'. for some
- it's a key thing, for others it could be just another list of defaults
-* port classic installer so it works with fifa
-* make some sensible default profiles (eg desktop, server, ...)
-* make it work
-* when doing lvm install. copy /etc/lvm/backup to /etc on target (or maybe
-it can be regenerated with a command, i should look that up)
-* someday.. make a script '/arch/setup' that calls '/arch/fifa.sh interactive'
-
-
--- core/interactive --
-- bugs -
-* boot space 15 -> too large should be too small
-* swap space 0 -> invalid?
-* you always need to press ok before it does the action it just said it's
+
+Specifically:
+* core/interactive bug: boot space 15 -> too large should be too small
+* core/interactive bug: swap space 0 -> invalid?
+* core/interactive/lib-ui: you always need to press ok before it does the action it just said it's
doing (is it the same with previous installer?)
-- features -
-* more control over filesystems (lvm,dm_crypt, choose each FS and each size
-yourself)
+* core/interactive: try out different installation methods
+* core/base: implement as specified in README
+* core/quickinst: figure out what needs to be done and do it.
+* dieter/automatic: wait for yaourt --config fix
+
+
+BETA PHASE: try to get fifa on the (beta) installcd as an experimental, alternative installer.
+* involve broader community
+* setup bugtracker/roadmap thingie
+* fix everything
+
+
+PRODUCTION PHASE: totally replace /arch/setup and /arch/quickinst
+* fix everything even more
+* bribe devs
+* core/interactive: more control over filesystems (lvm, dm_crypt, choose each FS and each size yourself)
+ when doing lvm install. copy /etc/lvm/backup to /etc on target (or maybe
+ it can be regenerated with a command, i should look that up)
+
+
+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) ?
+* 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.
+
+
+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
+