SEUL-Leaders: seul-dev breakout

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

this describes my proposed breakout for the seul-dev group.
note: this is pretty much a one-pass writing right now.  expect typos.

context:
]top level groups are seul-sys, seul-pub, and seul-dev, from earlier sketching
]this weekend.  i'll put that sketch in anon ftp on cran for a little while, as
]seul.fig and seul.ps (so you don't need xfig to view it ;)
](quick synopsis: seul-sys is for seul-internal management (software tools,
]                  and hardware such as servers, etc),
]                 seul-pub is for public documents/communication.
]                 seul-dev is the development team.
]                 check the seul.[fig,ps] if you want more details)

this the the breakout of just the subgroups under seul-dev.
there are 6.  seul-dev-
 distrib
 install
 ui
 admin
 apps
 help

the original groups from omega's breakout were as follows.  i'll discuss
where things went as i go along:
 distrib   (akin to seul-dev-distrib, but severly butchered.  see below)
 installer (roughly seul-dev-install)
 administration (roughly seul-dev-admin)
 software  (roughly seul-dev-apps)
 publicity (seul-pub-*)
 documentation -- o internal doc *system* (ie seuldoc utilities) are
                    seul-sys-soft:seuldoc.
                  o document content itself is owned by whoever creates the
                    documents; but note that public docs will go through
                    seul-pub ownership before getting to the web, etc.
                  o documents/systems used by the seul *product* is the
                    reponsibility of seul-dev-help.  this may or may not
                    be the same stuff used right now for our internal
                    documentation.
 (new group: ui -- broken out of software to be a separate group.
                   you'll see why)

--------------------------------

so, quick descriptions of the new seul-dev breakout follow.

*** seul-dev-distrib: ***
  same name as before, totally different definition.

  this group assembles the actual distribution.

  basically, final configuration of _content_ for the distribution (the actual
  packages, as opposed to the pkg management system) is up to this group.
  (with input from various sources on what is desired, of course).

  where did everything else go?
   defining fs standards: up to the sys arch.  implementation by the
  admin group (def extended, see below!).
   pkg managers: same deal. def by sys archs.  implementation by admin.

  the scheme is that install/admin are set up a system such that various
  default/customized packagings can be configured (an extra layer of
  abstraction above the current concept of packages (sort of)), and the
  distrib group fills in the spaces in deciding how the contents of the
  seul distribution should really be grouped, and what users really want
  what configurations....

  this is a sufficiently abstracted concept that distrib can work on
  specifying our desires for the final system while admin simultaneously is
  still coding the actual system to support the desired configurations
  (and others, if done well!)

*** seul-dev-install: ***
  develops the installer.
  as before.

*** seul-dev-ui: ***
  abstract ui management.  two main responsibilities:
  1. common gui look and feel.  this group defines/writes the toolkits
   and conventions that should be used in all seul software, thus providing
   for something linux does not have now, which is a common look among
   all [seul] applications.  this makes the user more comfortable, and more
   productive, by being used to gui conventions between apps.  it also
   takes the work of creating good ui components into one group, hopefully
   with members specializing in ui design, to provide for high-quality
   designs that can be shared.
  2. define/code the main gui.
   the goal is to make the user never have to see a command line.
   provide window manager setups that will start the user off in a reasonable
   graphical evironment, and write interface toolkits for others (admin
   and app groups) to extend the content of the ui, without breaking the
   intended look and feel.

  basically, once the ui group is through with their work, no one else should
  have to specialize in gui design in order to create a good-looking seul app.

  but NOTE: there are a lot of gui toolkits already out there.
  i expect this group to reuse as much as possible, before inventing an
  entirely new system from scratch!  writing everything from scratch would
  be a huge, unnecessary undertaking.

*** seul-dev-admin: ***
  admin stuff. (extended a bit from previous definition)
  1. automated admin.  make things that need to happen happen.  cron
   jobs and bootup jobs to do scans and keep thing happy.  log rotations
   are an example of stuff written for this task.
  2. admin interface software - writing basic sysadmin apps/applets, and
   creating a [programming] interface to the admin database.
  3. seul's master database - which watches/logs all installs/deinstalls
   and keeps things in sync, and complains if things are messed up.
   will probably be closely tied to the package manager, as well as other
   utilities (tar, install, etc)

  BIG NOTE: on why distrib lost task #3 above.
  admin programs, the packager, the master db, and the layout of seul config
  files, will be VERY closely related.  trying to separate these into
  separate top-level groups would become an administrative headache.

*** seul-dev-apps: ***
  all user apps that are not the duty of another group.
  gather apps.  port/hack apps as necessary to fit into the seul spec.
  write any important apps/applets still missing.

*** seul-dev-help: ***
  the help system.
  1. write a help browser, and a spec for other apps to use for
   invoking/controlling it.
  2. specify the help document format.
  3. write some actual help docs too.  this group may also acquire
   specialists in writing documentation, to help other groups write docs.


-------
finally, note that the whole seul organization is hierarchically named,
so seul-dev-foo can easily name subgroups if necessary, but the exact
specification of those subgroups is left to to future resolution.  it will
make much more sense to do that breakup once we know exactly what tasks
are getting distributed.

and i know this breakout does not specify a lot of detail and interactions
between groups.  that will all get worked out in good time.

for now, i propose this as the official top-level organization scheme for
seul-dev.  comments, criticisms?

-luka
----------------------------------------------------------------------------
Simple End User Linux Leader Mailing list
----------------------------------------------------------------------------