SEUL: software map

[John Munoz <jmunoz@mho.net>]

I worry that this will get dropped, it has been so quiet, I wonder if
the project has collapsed under the weight of it's aspirations...

Here is a shot at a very basic map that will have to be mapped into
several potential install scenarios, them worked from top to bottom. 
The "chain" paradigm comes to mind: any weak link, and we have lost
another potential convert.  There would be several potential chains as
outlined by several previous mails: Network install, cd install, etc.,
with all the probable permutations. I am sure I have forgotten 10
necessary things...

Install dependencies:
Networking (pick one)
	Ethernet
	Modem
	Other (token ring, AX-25, etc)
Filesystem (pick two)
	Floppy
	HD (scsi or eide)
	CD (scsi or eide)
	NFS
Kernel
	C libs for recompile...	(to compile or not, modules are cool)
Display
	40x80 - do we really expect any of our users to use terminals?  Vi is
unfriendly precisely because of this requirement.
	Windowing/virtual consoles
Input Devices
	Kbd
	Mouse
Basic Data Representations
	Text (
	Binary
	html
	Database
	Scripting (Shell, Java, Perl) 	
	Programming

Have we selected a bsd or SystemV style config/init?
This could go on forever, but that is what requirements are about...

Sam Revitch wrote:
>There will have to be some way to mask startup messages from
>the user like win95 does with that logo screen.

I have trouble with this.  One, we are back to "are we going to support
vga at boot time?" (I think we should).
 I think there is lots that could make it more intelligible, pretty,
etc., but one of our goals should be to put info somewhere that the user
can get it if they want.  Maybe we could do like you say with an option
like windows ( logged boot see file bootlog.txt on root) in a menu
selection, but w95's convention of press F8 to get boot-mode menu is not
too intuitive.  Another approach might be to have the start-up menu say
"type dmesg to see start-up log... and mask it as you suggest, Eric.  I
still think that we should treat our target audience as if they could
learn, not as incapable of learning and dangerous with any information.
 
Greg Bell Writes:
>We can get all the information from the appropriate (RPM, DEB, etc) >themselves so why not just make a general installer???

 Ohhhh Yeah! Regardless of our long-term plans, this is a fast way to
get a working base distribution out the door.  This will be a great
short term plan, will not require us to decide on a distribution right
away, and will put us in the position of co-operating with several
distributions instead of competing with them and duplicating their
efforts on a separate branch of a code development tree (read
non-resusable effort).

  I just read Peter Luka's mail, and this all sounds like tha project
mail might start up again.  The Organizational structure sounds good. 
What about test?  Should there be a separate list?  The key here will be
communication between developers and testers.  The Developers should
unit test this code.  What has always been the hard part is to do a
decent job of documenting the intricacies of the implementation so that
an "objective" audit of the finished product can be carried out
independently at the same time that the integration testing is being
done.  Obviously, more testing on more different machines will improve
our chances of developing a robust product, if we know how it is
supposed to work, and if we can use the feedback the testing generates.  
  This will require some attention to how we communicate, especially
since we only work across the web.  As I understand it, we will have web
space somewhere for each project.  There should be a heirarchical
requirements definition for each area, and possibly some sort of defect
tracking tool.  Any ideas on a freebie?  I use Pure's DDTS (html based)
and find it invaluable...  We do alot of our requirements based on it
too.  It is highly configurable due to it's perl based engine.

  Regardless, attention to automation of some of these tests will be
extremely important to efficient use of testing resources, and to good
coverage of code.  I think that there is a lot to dicuss in terms of
testing hooks for test drivers/automation, QA process, allocation of
responsablilties for unit test, documentation, and integration, test
coverage, repeatability of tests, and target machines.

-- 
John Munoz:  jmunoz at mho.net. Remove nospam from Reply address, or
change at to @  No unsolicited ads Please!  Support the Anti-Spam bill. 
Join at http:/www/cauce.org/