>> I'm not familiar with the packages that implement the server, nor what the
>> development, testing and installation process is, but I'd love to pair with
>> someone on fixing the responsiveness issue and learn.

It's all here:

   http://wiki.squeak.org/squeak/6365

This is what source.squeak.org is running.  It installs and runs clean
(in Linux).  It never saves the running image.

Every serious Squeak developer should do it on their laptop, so they
can have the revision history for their own proprietary code, not just
the source.squeak.org repositories.

Anyone wanting to learn about and work on our code repository should
do it on their laptops, as it's a great place to test fixes and
upgrades before putting them into production source.squeak.org server.
Once you do the installation step, my guess is you'll be able to find
the diff'ing in the code in a short amount of time.  But it needs to
be tested.

> Chris, are you interested in working with Eliot on this?

Yes, but I am leaving in less than 5 hours to depart for a month long
holiday, and I still need to sleep.  I just finished all day packing
sat down for a brief unwind relax and saw "URGENT"..   :)

I went through a lot of work to make the above process lucid and
smooth.  It's time to cash in.  :)  If you try it, you will go from 5%
to 95% knowledge about it in one evening.

I plan to check on-line things in the evenings during my holiday, I
can assist limited.

  - Chris


> I don't think I
> can help directly but I do have some experience with the older squeaksource.com
> system, and I'm interested in getting that updated at some point so if I
> can offer some help without getting in the way I am happy to do so.
>
> Eliot, I suspect that Chris cleared up one problem when he recently restarted
> the image, but that the diff processing that you mention is /also/ a problem
> and is worth follow up separately. The reason I say this is that I was getting
> commit timeouts on even trivial updates, and that problem went away after the
> server restart. But if commit timeouts still happen for a VMMaker commit, then
> it is very likely due to the diff processing.
>
> If in fact the diff processing for mailing list updates is the culprit, and
> if this is something that could be relegated to a background process completely
> separate from the user interactions, then I would be tempted to try putting
> the mailing list processing into a #forkHeadlessSqueakAndDoThenQuit: block.
> Any interest?
>
> Dave
>