[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL-Leaders: seul-dev breakout
this describes my proposed breakout for the seul-dev group.
note: this is pretty much a one-pass writing right now. expect typos.
]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-
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)
documentation -- o internal doc *system* (ie seuldoc utilities) are
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
(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
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.
*** 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
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?
Simple End User Linux Leader Mailing list