plans

[Luka (Peter) <luka@mit.edu>]

so, here's how things look:

the big-picture of goals i sent earlier seems pretty much on track.
at least, it's good enough to work from for now, but should become more
fully developed as we have time.

as far as what seemed to be the #1 debate here, the answer seems to be this:
we 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).  so as soon as mail goes out to seul-project that things are moving,
the first thing we'll need is to have a list of ideas for each group of
"the right kind of stuff" to be working on.

i don't think we'll need to do any major group restructuring.
something we will need to do, however, is 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, i think.

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.

--- 

THE PART FOR EVERYONE TO READ:

so, mail to be sent friday evening to seul-project, if you all like it
(or don't complain enough):

o announce dev lists.
o announce the general goals we've come up with.
o quick explanation of short/long-term strategy.
o divide into groups and give each it's focus and let is start work.
o keep debate about these structural decisions open on the seul-project list,
  as appropriate.

if any leaders are having net problems now, or will be otherwise
inconvenienced this weekend, let us know.  it's not a terrible, unsolvable
problem if you are, but it could be bad if we don't know about it.

---

THE PART FOR EVERYONE TO READ THE RIGHT PART OF (at least)

key groups, and their tasks (this is my assessment, feel free to argue it):
1. seul-dev-help
  this is well under development just by ken, and i think we can get
pretty far with it fast.  ken: can you get the code you have onto cran soon,
so interested people can start getting into it?
  have you given thought to what doc format to use (at least as far as
requirements specs)?  you'll probably find yourself debating this with
various seul-project members as soon as the group starts talking.

2. the s.e.g.
  the mission: 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 (which seems quite well equipped to
do this, as far as the type of personnel they have), 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, at least internally, with
evidence for those views from the input that was collected).
  there should be a system set up for gathering input on this info from
people with minimal pain.  the good choice to start with would be an email
gateway, i think, which can just be freeform input for now.  this can also
be made web-accessible, for public input.  the s.e.g. can then work at their
own pace on refining this interface to get the right amount of structure
in to make their jobs easier.  they'll also need to figure out what method
to use for indexing data.  i suggest looking at the sdoc (seul document)
standard we came up with (ask omega/arma/me for more info), but also consider
other documentation formats.  we're still just starting out, so now is the
time to test things/argue what is best to use, and then go with a good choice.

3. seul-dev-apps
  micah is leading this one, and i know for a fact there are a lot of people
interested in this area.  i expect the group will be doing some actual
development, but the key priority when starting out is to gather info about
what already exists.  there are a lot of apps out there, and i get the
increasing impression that no one really has any clue 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, and then making sure that you can index other
apps efficiently (both apps created by your group, and found lying around
(after you ask the question "does this exist" and find the answer to be
"yes", especially)).
  micah: you'll need to steer at least a few people into helping with this
sort of work.  i think there will be a natural tendency among developers in
this group to want to code, rather than catalogue things.


so, leaders of those 3 groups should try to keep constant status reports
and feedback going through seul-leaders over the next few weeks.  it will
be pretty intense.


groups that are getting squashed a bit for now, and why:
1. installer.  i don't think we have the backing for actual hardcore
 development of this, even though we do have a pretty extensive requirements
 spec.  so, if interest is expressed in actual development here (unless its
 incredibly more than i anticipate), i think the project to do is the
 reworking of [c,p,whatever]fdisk.  it should be well-abstracted to have a
 back/front-end separation; the backend should be robust; the frontend should
 be "ok" (at least equiv to the current stuff); the system overall should
 still be reasonably lean, and also easy to maintain, since we'll be doing
 more with it later.  and if this works out well, then the groups is
 ready to expand. if not, well...

2. gui.  we don't have anywhere near the power we need to do this ourselves
 from the ground-up, and there are other groups doing just that, all the
 way up to the standards level.  so end-product development is just not
 going to happen here (at least not in the scope defined).  rather, ppl
 interested in this group should get pretty intimate 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.

3. admin.  this group is badly named.
 not admin in terms of apps to make sysadmining easier - those can actually
 be lumped into the apps group as they are now.  user level apps like that
 written by this group would be intended to sit on top of the more
 key product of this group, which is a good system abstraction
 layer for linux.  this would include various huge design undertakings
 that i expect i'll give a dissertation on sometime soon, but basically,
 i don't think we want to dive into this area unless we have someone who
 knows it well already and is willing to put a lot of time into it.
 i would actually enjoy taking this myself later this/next year, but i
 definitely would not have time to give it what it needs right now.

4. distrib.
  well... tasks are defining desired system components, and packaging
  the final distrib.  nothing that really fits with the current state at all.

---

of course, all of the above is open for debate.
send any comments you have.
as far as my schedule, i now have one more problem set to finish for class
tomorrow (yes, i did get unexpectedly hosed with work when this week started),
and then i should finally be back to having spare time friday evening.

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