You raise a lot of issues, Chris.  A lot of these are actually better,
if you the docs would just point you better.  Some are getting better, I
think, but certainly still need work.

A few resources you should have in mind:

1. There is a Debian package of Squeak, but it is not in Debian proper
because of licensing disputes.  (If you have any idea how to resolve
that, it would be great to know -- writing to debian-legal has just
gotten me into a never-progressing debate.)  Anyway, on the swiki, go to
"Downloading Squeak", then "Download for Unix", and then "Squeak for
Debian Users":

	http://minnow.cc.gatech.edu/squeak/3616


2. There is a "stable 3.7 universe" release which has loadable Comanche.
 Grab the 3.7univ image from the Debian repository, or go to .  I know
that that version basically works, because an older version of Universes
was using that version.  (I've since dumped it in favor of a
StringSocket-based protocol, augmented by a static webserver to help
people behind firewalls -- which is the main reason to use HTTP outside
of real web browsers.)


That sucks about the man page.  I don't honestly have time to work on
it, though....  You might want to poke around on the web and see if you
can find a good description of the arguments.  Honestly, though, you
don't need most of those options by far.


Okay, that's what's out there.  For future directions, you mention a few
things as well.

chris at workinglinux.com wrote:
> In the Debian community, package maintainers, usually different people
> than the developers, do extensive testing before publishing anything - I
> think this separation of roles might contribute significantly to overall
> quality and fewer bugs released.  This may slow releases down a bit, but
> the much improved quality has greatly enhanced Debian's reputation and
> popularity.  Besides, whats the rush, anyway?  Don't get enough rushing
> at work?

To pick a nit, individual maintainers aren't that awesome.  However,
they are hooked into a process that gradually leads towards stable
releases.   Part of this is simply having a bug tracker; even if you
aren't a great maintainer, you will have pressure to remove bugs from
your own area of the bug tracker!  Nobody wants their package to have 10
major bugs sitting there.

Anyway, one thing we should adopt, IMHO, is the notion of generating
stable *sets* of packages.  Additionally, we should adopt their approach
of not breaking compatibility so much.  It's easy to say "let's move to
the next great thing in Squeak", but all too often that battle cry seems
to amount to loading half-working code that breaks compatibility with
existing code.  All other things aside, we simply have to be careful
about breaking code that *uses* Squeak.


They do indeed take 1-2 years to produce new stable releases.  I don't
know whether we will end up in the same boat.  They, like us, seem to
have trouble finding volunteers to help with those last several release
critical bugs.  I agree that it's worth it, though, so long as it
doesn't take any longer than this.  Having an occasional stable release
is a very valuable thing.  It lets people work in Squeak without dealing
with the day to day errors that developers are adding.


> I have noticed that some Squeak packages do run SUnits test as the last
> step of install, a practice I like a lot and wish were more widespread.

I don't really like this kind of thing, personally.  I wish packages
would quietly load and unload and not try to get in my face with helpful
offers.  Automatic test-running applies to every single package, and
thus it should be supported in the test loader, not as a part of each
package.

Same with documentation, configuration options, extra load options, and
dependencies.  Don't say "Would you like to load *mumble*"; put it as a
"Recommends" dependency.  Don't pop up a workspace -- install a document
into the system documentation repository.



-Lex