Where Squeak is Headed [was: Module discussion]

danielv at netvision.net.il danielv at netvision.net.il
Sat Nov 9 15:08:32 UTC 2002


I volunteer to be part of the updates stream group.


A few comments about the future role of the update stream -

I think SqueakMap is right now a good way to distribute what we'd call
goodies, and also many of the kind of larger tools/systems that used to
be integrated in past directly into the image (speech synthesis, for
example, as Connectors are now distributed in SM). 

People, as they post their work to SM are constrained, however, by
various in the image.

Examples include:
- applications posted on SqueakMap could appear in the open menu, if
code for a dynamic open menu was in the image.
- The FileList refactoring that's in 3.3a would allow the simple
addition of packages that add entries to the FileList.
- Many applications that use sockets could handle errors more gracefully
if sockets threw exceptions instead of deciding to wait, or asking the
user directly. 
- Many packages could be more usable and useful if PluggableMorphLists
were much faster, and allowed colored or bold items.

I think the update stream should now be used mainly to fix these sort of
problems, rather than introducing new functionality, which would be
better released through SM.

This means a change in the criteria for inclusion of things in the image
- the focus would be "does this make Squeak freer, removing constraints
and complexity?". 

It also means changes to our contribution process - the group
maintaining the update stream will definitely not be able to know and
judge the effect of changes on all packages. Feedback from the people
that depend on/are affected by the change will become even more
important. 

It may be a good idea to change the process formally - for example,
deciding that changes will be considered for the update stream if they
are endorsed/used by two maintainers of different packages. This will
also encourage people to get and give more feedback

A second role for the update stream might be to incrementally remove
existing applications from the image, once they find a maintainer and
appear as complete packages on SM.

Daniel Vainsencher

> Michael shared with me one other topic raised at the OOPSLA BOF, but not included in the public report.  Here's the wording I saw:
> 
> 	"The suggestion is to hand management of the update stream over to a group
> 	of experienced Squeakers. This group will manage the review and publishing
> 	process and have SqC as advisors in the background.
> 	Candidates right now are Göran, Doug, Ned and Tim (you did volunteer,
> 	didn't you? ;-) ). Volunteers, comments, vetos are welcome."
> 
> 	- Dan



More information about the Squeak-dev mailing list