Subject: [REPORT] Summer ends
Hi fellow Squeakers!
Lots of time has gone by and we - the Coordinators - have been pretty
silent for a while due to various personal reasons mainly. But we are
now getting back into gear and stuff looks pretty good all in all in the
land of the mouse.
This is a long report - but there is much to report. :)
NOTE: All reports available on http://swiki.krampe.se/castaways/8
Staring at the navel
Before this report I asked the other coords (Doug, Cees, Marcus) a few
questions about how we work and what we do. The net result can be
summarized like this:
- We think the Team model is good and is working. This doesn't mean all
*Teams* are working though. Coordination of the teams (our job) can be
also improved, we should simply do more of it. :)
- We think our main job is just that - coordinating the Teams and making
sure dropped issues gets picked up, teams are formed, leaders assigned,
teams dispersed etc. And writing these reports.
- If we ever end up having to make decisions that don't naturally fit in
any of our Teams, then yes, we will make them. But this will be ad hoc
- We have agreed to enlarge the group, and possibly also let one or two
of us go. Yes, we need to start circulate a bit.
Just sent out. Deadline to answer is 23rd, results will be published a
day or two after. I will put the survey questions up on the Coordinator
Swiki together with the results.
I assume you all saw Stephane's announcement of the formation of the
Squeak foundation. Exactly how the foundation relates to the
Coordinators etc is still a bit unclear - Stef did the right thing and
just "did it" - so now we are discussing how to evolve from here, and
btw, that discussion can be held in public IMHO.
In short I/we are wondering if the two entities really need to be *two*
:) or if we should merge them. Feel free to post thoughts on it.
The Coordinator's job is pretty clear, and I just described it earlier
in this report (see above). The job of the foundation is pretty wide,
but it doesn't (well, that is my perception of the goals listed at this
time) explicitly list goals for the development of Squeak itself - at
least not clearly.
So would it be best to have a single entity? Or is there a point in
having the two groups separate? Personally I am leaning heavily towards
declaring the two groups one, but I want to hear more thoughts. If we do
merge them then I think the goals needs to be revised.
And yes, all this might sound a bit odd - after all both Marcus and I
are in the Coordinator's group - so we are already "merged" in the sense
of overlapping people. But the two entities are still different - which
is good btw.
Anyway, the initiative is good and we will figure it out with your help.
A few days back I asked for short status reports from all Teams, and
here they are in one way or another.
I have not received any answer from Dan about a short progress report.
It seems to me this team has stalled, but we will see if Dan pops up and
gives us something later on. I will harass him a bit more. :)
Cees is excused for not writing down a report (given his involvement in
the Katrina disaster) but as we all have seen Juan Vuletich has
delivered a first result from Morphic Splitters, nice! It has already
been included in 3.9 alpha.
This is quoted from one of Juan's latest postings:
"This is the first MorphicSplitters change set. I prepared it for
3.9a-6690. It creates a few packages and does a massive categorization
of classes and methods, to fill them. It does not modify any method or
class definition. I believe this is a good moment to include it in the
It is at http://webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st
(I didn't attach it to this message because there is a 100kb limit).
Next steps in the MorphicSplitters project will involve real
refactoring, to allow unloading of the EToys and MorphicExtras packages.
We're using MudPie and some removal scripts based on one by Dan for the
analysis. I believe
these will be useful for other refactoring efforts.
I'd like to thank to Cees, Edgar, Daniel, Dan and anyone else who helped
in some way."
One of the major goals of the packages team was to enable the base image
to be managed primarily as a set of packages rather than through the
update stream. This is currently happening with Squeak 3.9 alpha, which
has been divided into Monticello packages and is being maintained
entirely through a dedicated SqueakSource installation. The process is
described in more detail at http://minnow.cc.gatech.edu/squeak/5718.
Special thanks to Andreas for doing the initial Squeak packaging, Doug
for getting the source.squeakfoundation.org server up and running, and
Marcus for managing the new packaged 3.9a image.
Andreas announced on the packages list a restructuring that places the
development tools into a fully unloadable package. An image with the
tools already unloaded is available at
Integrating this work should be a high priority for the team in the
future. Another recent and relevant development is the release by
Michal Starke of Kabungu:
...the first dependency engine for SqueakMap; this may provide good
basis for the SqueakMap/Universes conceptual integration that was
discussed shortly after the packages team was formed.
Note by Gˆran: I have already promised Michal to integrate Kabungu ASAP
in SM, we have exchanged a few emails in private and Kabungu is quite
similar to my model - and still different - but the differences may very
well be for the good. But above all - the code runs today. :)
This is "done for the time being". We might consider closing this team,
Brian Brown has no more time to spare and this stuff is almost all in
3.9a. So good job Brian! :)
"Technically I am the "team leader" for the 3.9a team, but for most
practical purposes I have taken over lately as the leader of the
packages team, and Marcus has taken over most of the 3.9a work.
With the packages team, considerable progress has been made... 3.9a is
now partitioned into packages! (I guess this counts as 3.9a progress
On the packages side, the SqueakSource repository containing the 3.9a
packages has been set up and is up and running at
http://source.squeakfoundation.org. This is a special SqueakSource
install (based on code from Bert) which supports generating .mcd (diff)
files, which results in much faster incremental updating of MC packages
than loading entire .mcz files.
The items still to-do are to add the rest of the support for the Hybrid
MC/Update Stream model, which is really just this: When someone
requests to load updates, we first check the update stream for do-its,
then we load the latest MC packages (in a predefined order). (This part
should not be too hard... getting the new SS server running seemed to be
the hard part.) This page has some details:
There are also some potential stability issues with SS which are being
On the 3.9a content side, Marcus has been doing lots of harvesting (as
can be seen by browsing the SS server). Also, Toolbuilder changes have
gone in (I think?), LookEnhancements, PreferenceBrowser, and there is
serious discussion of Traits."
File Area Team
Nothing much happening, but Bruce is reliable and that is what counts!
"Since the last report we've updated the unix/linux packages to use the
fixed 3.8 image and have uploaded new MacVMs."
Ken beat me to it and reported separately, nothing much more to say
except that David Shaffer signed up to help:
Well, we now have box2 up and running and we are gradually moving all
services off of box1. Other than that there is not much to report I
think, right Ken?
Website Team Report from Jason Rogers:
- Content for the new site is coming along nicely, but we aren't quite
- We have added a new team member: David Brooks
- We continue to have stability issues with the new site and are working
on improving that
- The current plan is to "release" the new site and take the old one
offline as soon as we reach a stable juncture
(after this was written help has come forward with a new hopefully
better working image and we hope to see the site coming up Real Soon
Someone opened the box, and no, it wasn't me. I tried to shut it, but
hey, this is a force of nature - who am I to think it would stay closed?
:) I am talking about the recent licensing thread, as you might imagine.
Without getting into the details Craig told us on IRC that he is
communicating with "the fruit company" in this regard together with...
well, let's say he has some very prominent help. We (coordinators) will
keep ourselves posted with Craig so that we are aware of the status of
that ongoing communication and we think it seems wise to wait and see
the result because Craig together with "prominent helpers" have a good
personal incentive to get closure on this.
Craig thus is our "point man" on this from now on so if anyone has
something interesting/important in this matter - contact Craig. And
perhaps that will close the lid for now? No? Even if I sit on it? Sigh.
Developer initials evolved
Ever since SM2 was released the developer initials have been registered
on SM. When I released SM2 I migrated all known initials from the Squeak
Swiki page into SM.
The idea is that you create an SM account to make sure your dev initials
are unique and known to the rest of us. This also maps your initials to
a name and an email. Now, it is pretty important to us that this is a
real name because the developer initials are used to track code. And if
we don't know who has written some code then we have the problem of not
knowing the license for that code - nor do we know whom to ask if we
want to change the license of that code in the future etc.
The upcoming website has a "community howto" text in which we encourage
new Squeak developers to register their developer initials so that we
can keep track of ourselves and code authorship.
Recently Stephane brought up the problem of mentally mapping dev ids to
real people - it isn't that easy since we now have more than 300
registered accounts on SM. MC only records the dev initials in an MC
version, so that is all there is today.
My suggestion is that we do the following:
1. Add a field to SMAccount in which we can keep old developer initials.
This way people can change their username on SM (=dev initials) and keep
the old ones in that field, typically separated with a space. This means
all published old code can still be mapped to a person and thus
authorship is known.
2. Enhance our tools to perhaps map the id to SM and show the real name
etc. I have used this in the "split changesets"-mechanism (not yet
integrated in 3.9alpha) which is able to split a changeset based on
PackageInfo boundaries, compose an email of the splits and the original
changeset and send that to all maintainers of said packages. This means
I map PackageInfo->SMPackage->all maintainers and co-maintainers->their
emails. Now, this is a powerful thing to have and I have written about
the importance of this mapping lots of times - please let us finally
appreciate the importance of SM in this regard.
3. Also enhance the changeset tools and MC so that they not only include
the dev initial but also the full name and email from SM. Sure, a bit
redundant, but the email might change in the future, but whatever - then
you can always look up the current one using the dev id.
Now, I predict only a few will start changing the dev initials to their
full name like Stephane suggests - so without #2 and #3 above it will
still be very hard to mentally map the dev id yourself.
If we can agree on this scheme I can take on myself to hack this.
And thus ends this report, hopefully with not too many glaring omissions
regards, Gˆran Krampe
Tasks identified in this report (and left from the previous one)
- Ponder the merge/separation of Coordinators/Foundation. Views?
- Think about the Team model, what can we improve? Think, post. Subject
- Burning issues! Read, think, post. Subject tag: [BURN]
- Follow Doug's lead on 3.9. Harvest etc.
- Find 1-2 more Coordinators
- Compile and publish stakeholder survey results
- Figure out how to merge/relate to Foundation.
- Get better at harassing the Team leaders :) :)
- Communicate with Craig to see where the license talks lead
- Get the new website out :)
- Move SM to box2
- Integrate Kabungu in SM
- Possibly hack SM + some tools for developer initials proposal
Volunteers - not sure if these are fully done so leaving them in:
- Worlds Of Squeak remake in 3.8 ??
- Get 3.8 properly published on the Squeak Swiki ??