[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

More seul-leader information



I haven't gotten many responses back from my mail on Saturday morning. So
I'm going to try saying this a bit differently: let me know ASAP if you want
to lead one of the SEUL-dev groups. So far mjackson@seul.org is in charge of
seul-pub, nickm@mit.edu is in charge of seul-dev-admin, grep@oriole.sbay.org
is in charge of seul-dev-distrib. I have added those three to the seul-leaders
mailing list, where discussion about inter-devgroup topics among leaders
should be taking place RSN. George and Nick should get back to me about
accounts on seul.org, so I can set you up with a mail address there. If any
of the rest of you are interested in leading another group (it is possible to
have multiple leaders for a given group, as long as they work out how things
are going to work), let me know so I can add you to seul-leaders.

I intend to force all SEUL traffic onto the seul-dev-* lists within the next
few days. I'm going to solidify the task divisions between groups, then
send that out, create a seul-discuss@seul.org list for people who want to
keep blithering, make seul-project@seul.org a *moderated* list if high
traffic persists that should be elsewhere, and maybe that will make things
work more smoothly.

Here's a current list of who's in charge of which projects, large or
small. Soon all of this will move over to the website (right Paul?) where
people can view it and keep track of things themselves.

***************************************************************************

seul-leaders:
Erik Walthensen <omega@seul.org>
Roger Dingledine <arma@seul.org>

seul-discuss: (no plan yet)

seul-project: (no plan yet)

seul-dev-admin:
Nick Mathewson <nickm@mit.edu> (leader)

seul-dev-apps: (no leader yet)
starsend@interlog.com
Kai Wetzel <k.wetzel@welfen-netz.com>

seul-dev-distrib:
George Bonser <grep@oriole.sbay.org> (leader)
Magnus Lycka <magnus.lycka@tripnet.se> (status unknown)

seul-dev-help:
twoducks@seul.org (leader)

seul-dev-install: (no leader yet)

seul-dev-ui: (no leader yet)

seul-pub: 
Martin Jackson <mjackson@seul.org> (leader)
Paul Anderson <paul@geeky1.ebtech.net> (website maintenance)

seul-seg:
Aldo <solaris@cicei.ulpgc.es> (leader)

gnome/kde faq:
Jean Francois Martinez <jfm2@club-internet.fr>
(I'm actually not certain he's accepted this yet...oops. :)

monitor database:
William Wilson <fluffy@dunadan.com>

***************************************************************************

I've included below a mail sent by Luka long ago, with other ideas on
the task division between seul-dev- groups. Over the next little while,
I'm going to figure out exactly what the various seul-dev- groups are
supposed to do. Clearly I should make this happen before I try to migrate
people onto those lists. :)

If you have any thoughts on what you think your list should be, based
mostly on the last mail I sent out (the one below looks like it has some
neat ideas, but it's pretty far out of date), please let me know (mail
to seul@seul.org so Omega gets it too).

Thanks,
--Roger (arma@seul.org)

***************************************************************************

From: "Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>
Subject: seul system design  (sent to seul-project)
Date: Sat, 09 Aug 1997 15:29:19 EDT

this is the beginning of the overall seul system design. read it and comment.

"extensions" model:
 we'll start by developing seul "extensions" rather than a full distribution.
this means that once we are more experienced with what exists, and how it
actually works, we can in the long run "seul-ify" any distribution.
 you can think of the extensions as packages that either add new seul utilities
to the system, or replace existing utils with seul versions.
 several similar extensions can be grouped into seul extension modules, which
happen to correspond to our development groups - this is not a coincidence.

specific extension modules: (and corresponding group)
 1. replace the installer.
    (seul-dev-install)
 2. seul db - sits beside the main package manager, and keeps track of all
    sorts of things ("registry"ish).  used by everything to keep the runtime
    system synchronized.
    (seul-dev-admin)
 3. seul gui.  standardized, friendly, and integrates with seul-db ((2) above)
    (seul-dev-ui)
 4. help system.  integrates with other stuff.
    (seul-dev-help)
 5. seul apps.  includes base stuff direct from us (eg seul [graphical] admin
    tools), plus "seul-approved" apps, which all need to integrate to some
    extent with the rest of our stuff.
    (seul-dev-app, or admin/help group for low-level admin/help app coding.)
 6. define distributions of "package-sets" targeted at specific user groups.
    (such as home, school, business, marine biology, etc).
    (seul-dev-distrib)

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

now for details.  threads and lists:

i'm going to start separate threads on each of these modules in a moment.
the first message i post for each will be an overview of the module and its
current status.

after a bit of discussion this way, i think we will break off six mailing lists,
so that once we're pretty happy with the general layout, everyone can focus on
particular groups and start dealing with details.

for now, discussion should focus on issues with defining the groups and their
interactions.  if you see problems in one group that will impact another, now
is the time to discuss these *on the appropriate thread*.  and if you see
problems at a higher level, or which involve multiple groups to a great
extent (which does indicate a problem, btw), then respond to this thread.

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

group interactions:

first one important point (on admin and ui):
to pull this off, we'll need some glue in the form of interface libs  for the
gui and the db, mainly.  this means that the ui and admin groups will be writing
a lot of stuff that will be used mainly by _other_ groups -  they will need to
keep this in mind when building stuff. 
good abstraction is encouraged in everything, of course, but it is */essential/*
in these two groups.  something to keep in mind...

the following is a list of dependencies among groups.  ("provides nothing" does
not mean the group is doing nothing - it means they are not producing something
that another group has to wait on to do their own work; this is a good thing.)

[warning: i guarantee this is buggy.  i have not spent enough time on this yet]

 1. seul-dev-install
    provides: installer support for seul package-systems. (6)
    depends:  nothing
    depends-loosely:  may eventually reuse gui toolkit; (3)
                      may eventually reuse help system; (4)
                      definition of seul package-system/seul db lib; (2)
                      scope of seul distrib definition. (6)

 2. seul-dev-admin
    provides: seul db lib. (1,4,5)
    depends:  nothing
    depends-loosely:  will reuse gui toolkit for app frontends. (3)
                      scope of seul distrib definition. (6)

 3. seul-dev-ui
    provides: seul gui lib (1,4,5)
              (probably in terms of a 3rd party toolkit, but defined and
               hacked/abstracted by this group)
    depends:  nothing
    depends-loosely:  nothing

 4. seul-dev-help
    provides: help system services (1,5)
    depends:  seul gui lib; (3)
              seul db lib (for help apps) (2)
    depends-loosely:  nothing

 5. seul-dev-app
    provides: nothing
    depends:  gui lib; (3)
              seul-db lib; (2)
              help system services. (4)
    depends-loosely:  nothing

 6. seul-dev-distrib
    provides: seul distrib definition (1)
    depends:  ability of installer to support the distrib definition
              (package-systems) (1)
    depends-loosely:  nothing

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

the shape of things.
a quick overview in english of what's actually going on in the seul system
being designed:

1. we are trying to create a linux distribution system that supports a higher-
level packaging scheme, so that entire user-sets can pop in a floppy,
click once or twice, wait a while, and then have a functioning linux system
in front of them (in most cases.)
the high-level package system allows us to distribute a few common configs
(home, business, school, etc), as defined by the distrib group, who should
research the appropriate config for these groups (and which groups we should
actaully support).  also, different groups (eg companies) can configure a
seul installer to meet their own setup needs as well, to allow there workers/
students/clients/whatever to get a system customized for their setup with
just a few clicks.

2. once the system is running, it will support an abstract interface through
 integrated [graphical] apps, a help system, and holistic admin db system,
 that does a lot more than current package managers, and helps things stay
 synchronized through the entire system, without hindering the user too much.

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

  as a last thing, a good analogy for the seul system, courtesy of omega, who
  has been checking my sanity and providing extra ideas as i work on this...

  Linux is Legos - lots of parts that you can do anything with.  Existing
  distributions are like the starter sets, or those that give you a large
  selection of parts but nothing specific to build.
  SEUL is like a large model set, with lots of alternate models you can build.

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

-luka

===
SEUL-Leaders list, seul-leaders-request@seul.org
===