[Squeakfoundation]About the structure SqF might create

squeakfoundation@lists.squeakfoundation.org squeakfoundation@lists.squeakfoundation.org
Sun, 27 May 2001 02:57:31 +0300


Hi all, I just now read the archives (very interesting, looks like
something important is starting here).

This is what I imagine happening now, from everything I've heard here,
and what I have been missing so far -
* A few people take on the task of organizing the real squeak.org. By
"the real", I mean that like SqC has mentioned, Squeak programmers are
one of 3 audiences. And just like kids, or any audience, they (we)
deserve a coherent view on Squeak. Handhelds.org is a good example of a
site that combines a fixed part and a wiki part pretty seamlessly, and I
think that's a bit like what we want to look like. This task has lots of
subgoals, but at the end, a programmer should start from
http://www.squeak.org and be presented with all the glory of technical
Squeak, including learning resources, upto-date downloads, and links to
the authoritative SqD's.

* After SqSt is unveiled (and I second the proposal I believe I read
about showing something even if it's status is officially "read only"),
we'll all break our heads on what the release process might change into
- depending on what new modularity we get. DanI made a proposal about
this - if I understand it correctly, it puts SqF where SqC is now, in
the sense of giving the rythm for releases.

I hope we can do something more ambitious. 

The Debian project has a cool technology where packages get updates
published on various servers, and people can query many servers at once
to decide what updates they want. This is very similar to what we
already have in update servers, except we have only one live stream. If
we can indeed split the image into loadable packages, we could have an
update stream for each package, and each with it's own rythm, the Debian
way.

I think one other positive influence dying to get into Squeak is the
practice of SUnit tests. SqF needs a way to keep packages from
stagnating or quietly drifting into incompatibility, and SUnit looks
like a great tool. If we decide the stable packages must have SUnit
tests, theres a role here for someone in SqF to coordinate the planning
and tracking of creating tests so that we get good coverage. It can be
SqF policy to check submitted code doesn't break the package it's
intended for, or any packages it should play nice with.

If SqF does nothing except make all Squeak technical info readily
accessible from a single site, and give us a framework where various
SqD's can maintain and advance the packages they're interested in
without stepping on one anothers toes, I'll be utterly delighted with
it.

What do you think?

Daniel