Time to get busy!

[Mike McDonald]

>From: "cosc19z5@bayou.uh.edu" <cosc19z5@Bayou.UH.EDU>
>Subject: Re: Time to get busy!
>To: lispos@math.gatech.edu
>Date: Sat, 3 May 1997 20:10:19 -0500 (CDT)
>
>>   OK everyone, enough talk It's time to get busy! :-) Why don't people
>> start picking projects that they're interested in?

  Ahmed asks a bunch of good questions about methodology.

  The way I would expect things to procede is by groups of people with
similar interests would get together probably via their own mailing
list, discuss amongst themselves what the goals are for their project,
develope an implementation plan and a set of ABIs (both that they'll
provide and that they'll need), mail that plan to the lispos group for
comments, update their plan, split the work up amongst the interested
parties along clean boundries, and start coding. I think each project
should have a "techical lead". Someone who coordinates the activities
of the participants, answers questions from both inside and outside
the project, and acts as a liason to the other projects that his
project interacts with. This is not a dictator position, more of a
facilitator. I'd expect the lead to be very knowledgable in the
particular area. A good general knowledge of lisp and large systems
wouldn't hurt either.

  As for time frame, each project will have its own time frame. We'll
need to do some coordinating between dependant projects inorder to
keep things progressing smoothly. Some projects like writing a tar
package should be realitively short in durations, maybe a couple of
weeks. Some projects like CLIM and the kernel are much longer term
projects.

Coding standards:

  First, I'd expect most projects to have their own package that
contains all of their exported symbols. Some projects may also have
one or more internal packages. For instance, the kernal project may
have a package called system which contains all of their supported
interfaces and It may have one internal package called
system-internals. Or they may decide to break things up into more
seperate and orthogonal packages, like system, gc, vm, ... It kind of
depends on the size of the projects. Big projects may have
subprojects, each in their own package. Of course, we'll have to
coordinate package names to avoid conflicts but that's not too
difficult.

  For each package, the sources for that package should reside in a
file hierarchy with the package name as the root, ie their should be a
directory called CLIM that contains the sources for the CLIM system.
Each package/project should have a system.lisp file in that root
directory that uses a defsystem to define that module, including
defining the package, any *features* that it adds, and any
configuration parameters that it relies upon. All a person has to do
is look into this one file to see what, if anything, he has to modify
to port it to another system. Serious bugs or shortcomings should be
listed at the beginning of the file as comments.


>My software engineering experience is non-existent (I code therefore
>I am), but shouldn't there be more formalism involved than just
>saying "We need a persistent OO store, Make It So!"?

  Well, I kind of expect the people who are interested in a persistant
object store (or any of the other projects) to go off, research what
has been done before, bounce ideas off each other, propose some ideas,
defend those ideas, build a prototype or two, try it out, and then do
it all over again. And again. And again. ... But so far, all we have
is a bunch of pontificators. :-)

  Mike McDonald
  mikemac@engr.sgi.com