newbie question (different newbie) - getting changes into Squeak problems

Peter Smet peter.smet at flinders.edu.au
Tue Jul 13 04:38:36 UTC 1999


>There now seems to be a large enough base of users outside Disney that
could
>cooperate to form a development group to design and maintain a parallel
version
>of Squeak (Squawk?) and respond to the growing needs of its growing
audience.
>
>I think this is necessary and volunteer be a part of such a group.
>
>Shall we begin to organize a group on the Squeak swiki? What do the veteran
>Squeakers think?
>
>-Mark Schwenk
> WellThot Inc.

Mark,

>From what I know of Linux development (which is not much), a 'code fork'
like such a parallel version is to be avoided at all costs. However, there
is no way that Linus can check and veto all the changes proposed for the
Linux kernel. By analogy, Squeak may get to the stage where Dan cannot
personally examine every proposed change set and its implications (I could
be wrong about this - nothing seems to be beyond Dan and Co). The solution
to this problem which has emerged for Linux development is a kind of
hierarchical delegation. For example, one group will work on infra-red
drivers, and their leader will make recommendations to Linus, another will
work on graphics modules or SMP. Because Linus knows and trusts the
judgement of these group leaders, he no longer has to painstakingly check
every line of code in the proposed additions.

One problem with Squeak, IMO, is that there are too many people (myself
included) all working independently. This may have something to do with the
history of Smalltalk (it can be difficult to integrate diverse images, etc)
or with the fact that we are still awaiting 'critical mass'. (This is why I
strongly believe we need as many newbies as possible). What I am hoping is
that the better projects (whatever better means) will gain more followers,
and become group projects. The pluggable web server may be the first example
of such a group project, but more of this needs to happen. The more groups
start coalescing around projects, the better. This will also help Dan and
Co., since the groups will become more independent, adding 'final products'
to Squeak that need less intervention by Disney.

As Linus has said on many occassions, the best thing to do is not something
that appears to be necessary for Linux (or Squeak), but something you
personally will find fun and useful. This way, you will always be passionate
about what you are coding (this is probably the single thing that makes open
source software of such high quality). However, if you need tools along the
way (and who doesn't) then you may find yourself filing in the code of
others. Here's where we can all help each other - if the code has
shortcomings either let the author know, or contribute an improvement to the
author. If the code is solid and useful, email Dan and ask for it to be
filed in to the base release, or as a standard add-on package. Once Dan
receives 5000 emails requesting something be included, he will probably take
a look at it :-)

If you are working on something alone, email this group about your design
decisions, problems, workarounds etc. I have received excellent code
suggestions  whenever I have done this (for example a Recursive Semaphore
implementation, and much other stuff). This will also help in 'seeding' new
groups interested in the same code. I guess what I am saying is, rather than
develop a parallel fork of Squeak, lets form groups around the code we want
included in Squeak, test it, improve it, pre-digest it, and send it to Dan
for consideration....

Anyway, this is turning into a bit of a rant so </rant>

Peter





More information about the Squeak-dev mailing list