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

SEUL: plans/actions

We're back now, and it's time to get this project going.  There's been
discussion on seul-leaders about the right direction to go, so here's the
outcome (open for further debate from anyone).  I'll start with what's and
go on to why's toward the end... 

I. What's happening. 

In the long run, we expect a seul-oriented distribution to appear, but
that's going to be a while yet.  In the short run, we want to focus on
building the components that will go into that distribution to form a
cohesive product focused on the end-user.  We also want those components
to be usable independently, so we can actually be producing useful
products right away.

Right now, we're going to focus on a few key areas that we already have
people working on and should be easy to produce useful stuff for.  This
will give us some relatively easy work and quick results, and be a good
way to start getting used to work on this project.

There are 6 dev groups (same as before), plus the new "seul expert group" 
(s.e.g.).  The s.e.g. is being run by Aldo-Pier Solari (solaris@ulpgc.es),
and is meant to acquire contacts with our target users and form a
knowledge base of their needs.  Each dev group has a mailing list.  Sign
on to whichever you want to read/work on. (see II below)

The groups that we will focus on are seul-dev-help, seul-dev-apps, and the
s.e.g. (the ones with leaders and momentum; surprise.)  The 4 remaining
groups will be downplayed somewhat unless someone starts doing real work
on them; omega and I will be acting as the contacts for those groups until
they get individual leaders. 

II. What to do now. 

Subscribe to any/all dev lists you're interested in (they're listed
below).  Someone will post in a day or two to get things started. If you
miss anything, these are archived off the web page, so you can check on
them there as well.  As I said, expect at least a day or two for things to
start up. 

To sub to list "listname", mail to majordomo@seul.mit.edu, with message

  subscribe listname

You can include as many subscribe lines in one message as you want; put
'end' on it's own line after all subs to tell majordomo to ignore .sig. 
You can sub to all groups if you wish to get a feel for them and decide
which you care about later.  To unsub from "listname", mail
majordomo@seul.mit.edu, with: 

  unsubscribe listname

IMPORTANT NOTE:  All the lists are @seul.mit.edu right now, as we're
dealing with some DNS issues.  seul.org should be fixed soon, but til then
make sure you send mail ONLY to seul.mit.edu!!  (mail to seul.org will

seul-project: This list.  For general discussion about the project

seul-dev-help: Seul help system development. 

seul-dev-apps: App indexing/development/adaptation. 

seul-dev-install: Installer overhaul. 

seul-dev-admin: Low-level system abstraction. 

seul-dev-ui: Gui system research/development. 

seul-dev-distrib: Spec/assembly of seul distribution components. 

III. Details. (what to expect soon) 

A. Key groups: 

1. seul-dev-help
  Group for producing a powerful, friendly, graphical help system for
linux.  Already well under development just by Ken Duck
(twoducks@globalserve.net).  With some more help, this should be able to
get pretty far quickly. 

2. seul expert group (s.e.g.) 
  This is a group of people to coordinate gathering large amounts of
knowledge about our intended userbase and their needs, based on factual
  Current goals: find out what's wrong with linux, and get into writing
exact details about what needs to be done (with prioritization) in order
to make it more user-friendly.  The group is going to need to take vague,
general input from the masses, the seul-project people, and any other
contacts they find useful, and turn them into very concrete statements
about what we want out of linux (backed up with evidence from the input
that was collected). 
  Aldo (solaris@ulpgc.es) is managing this, so contact him if you would
like to contribute as an end-user, or know a typical end-user who would
consider participating. 

3. seul-dev-apps
  Micah Yoder (yoderm@geocities.com) is leading the group.  This group
will be doing /some/ actual development, but the key priority now is to
gather info about what already does (or doesn't) exist.  There are a lot
of apps out there, and no one really has a good grasp on just how
extensive it is.  (Generally, when I ask a person "does this sound like an
app that has already been written", the answer is "I have no idea; maybe; 
do a search".) 
  So, collecting pointers to existing app indexes like SAL and the LSM
would be the first thing to do, then defining/adopting a format for
indexing other apps efficiently (both apps created by this group, and
found lying around un-indexed), and finally bringing together a single
starting point for searching for Linux apps. 

B. Groups that are getting downplayed a bit for now, and why:  (for one
thing, none of these have leaders yet, so until someone else steps in, I'd
the person to contact about any of these) 

1. Installer.  It doesn't seem like we have a lot of backing for actual
 development of this, even though we do have a pretty extensive requirements
 spec, though I may be mistaken. So if people are able and willing to
 start development here, I think the project to do is the reworking of
 fdisk (one of the major things in the spec we had earlier).  It should be
 well-abstracted to have a back/front-end separation; the back-end should be
 robust; the front-end should be "ok" (at least equivalentlent to the current stuff);
 the system overall should still be reasonably lean, and coded to be readable
 and easy to maintain.  So if you want to do this, just go ahead and get
 started.  And if this works out well and more people join in, then the group
 should be expanded once we see that happening...

2. Gui.  We don't have anywhere near the power we need to do this ourselves
 from the ground-up, and there other groups doing a lot of GUI innovations
 now (lip, etc).  So this would be a bad time for us to start end-product
 development for a seul GUI standard.  Rather, people interested in this group
 should just start getting familiar with what's going on in other groups, and
 see if that's good or bad, and formulate some proposals on what should be
 done by us or not done by us.  If another group is doing things right, tell
 us, and then you might go code for them so they can get work done faster. If
 other groups seem to be misguided, discuss why and what to do about it on
 this list.

3. Admin.
 (Note that this group is badly named, since the general connotion of
 sys-admin apps are actually an aspect of app software, which seul-dev-apps
 deals with.)  This group's main product is a good system abstraction layer
 for linux, which has not been thoroughly designed yet but will involve
 concepts such as the "seuldb" (the registry/install-shield-ish idea),
 extended package-manager abstractions, revising the standard interface to
 root operations, etc, all made to work together as a whole.  These things
 will require various huge design undertakings, which we don't want to dive
 into unless someone who knows the area well already is willing to put a lot
 of time into this.  If you are interested in this stuff, sub to the list,
 but expect mainly discussion and maybe some test-coding in the short-term.

4. Distrib.
  Well... tasks are defining desired system components, and packaging
  the final distrib.  Nothing that really fits with the current state at all.
  One thing that used to fall in this scope was target user analysis, which
  is now being done specifically by the s.e.g.

IV. More why's

As you may have noticed, a lot of stuff has been happening just recently
outside of seul, which is related to our own goals.  e.g. RedHat is
promoting commercial development for linux, hiring more people, and
getting ready for a new release.  TurboLinux is out (anyone tried it?). 
Linuxconf has had made several new releases (I saw "no longer has to
modify the standard SysV boot process" in recent release notes)...  you
get the idea. 

The point is that things are moving, and we don't want to lock into some
plan that will be obsolete by the time we complete it.  So, this is what
prompted a bit of discussion on what we really want/need to do before
getting back to work on seul.  General short and long term planning has
been worked on now, which takes in what we want to do, as well as what we
/can/ do, and how all of that may change over time. 

One of the major issues resolved was that of whether we should produce a
seul distribution, or let someone else handle distributing our stuff.  The
consensus at present seems to be that we do want an end-user targeted
distribution to appear at some point in the future, probably on the order
of 1-2 years, and we want it to be a good one, with a cohesive,
intelligently-designed interface.  It looks like RedHat and others have
something along these lines in mind, but we can't be sure exactly what
will actually happen except by waiting.  Thus, in the short term, we will
be coding stuff that should be useful in an integrated o/s distribution,
but should also be useful independently, and not overly dependent on the
existence of the grandiose back-end libs we're planning on creating (in
the scope of the slightly-misnamed 'admin' group). 

Whether group restructuring was needed was the other major issue.  Seems
like the answer is no, with the one possible exception that 'admin' is
kinda misnamed considering its purpose.  Oh, well; I couldn't think of a
better name that was worth changing to.  However, with regard to groups,
it will be necessary to focus attention (both of leaders and developers) 
in some groups more than others, since we don't have enough leadership
backing right now to get spread out across the full 6-group project
effectively. (Of course, if more people start working hard on these
projects, then they will naturally expand as that happens, and this is the
intended effect.)

All of this will allow us to get started quickly and actually produce
useful stuff, which will make us feel useful, and then keep doing more. It
will also let us get a feel for working as a group on some relatively easy
stuff at first, before we dive into doing major new innovations.

If you want more details, check the seul-leaders list archives.  Email
omega@omegacs.net or me or seul-project as appropriate if you can suggest
changes to make things work better. 

 Peter Luka            ...            luka@mit.edu
 SEUL Project development leader/systems architect