History and thoughts about "how" we work on the image together
goran at krampe.se
goran at krampe.se
Sat Oct 7 17:40:43 UTC 2006
(warning - long post - but possible containing some good info and
Hmmmmmm. Ok, triggered by Cees' post on his blog and other discsussions
on IRC I started wondering and questioning our established views on
"how" we should maintain and further develop the "official" Squeak
image. Hehe, we have *never* done that before, have we? ;)
Let us take a step back and look at what we have tried in the past:
1. In the beginning we had SqC, a tight team with full time dedicated
people. A few of the SqCers (Ted and Dan IIRC) worked as update stream
maintainers and did most "harvesting". It worked probably because of the
limited scale and the dedicated time. And because SqC held the rudder,
there was not much discussion going on. There were negative sides of
course - but if we focus on the actual work made on the image, this
model probably worked quite ok given the circumstances at the time.
After all, it is a classic model - a few people in control and most
others sending contributions that may or may not be accepted.
2. Then we moved to a model with a few people outside of SqC maintaining
the update stream and harvesting changes from the list (as before sent
as changesets to squeak-dev). This also worked for a while, but the
harvesters did not work full time nor did they get paid - so they got
really tired. :) And the rudder was not as firmly held, with both
positive and negative effects. One of the positive effects was that the
community probably had a more direct "saying" on what went in - it was a
first step in a gradual transfer of responsibility to the community at
3. As a response to this (the seemingly unsustainable harvesting model)
an new model formed that is based on dividing the image into different
parts (using PackageInfo that came about when Monticello was built) and
then trying to get people to take personal responsibility of those parts
("Stewards") and form smaller development teams around them. Most of us
saw this as the only way forward - and we also recognized that this was
the way that all the "rest" of the Squeak artifacts are maintained (see
666 packages on SM) - so why shouldn't it work also for the parts in the
With 3.9 this partitioning is now official since the 3.9 release team
took the partitioning and ran with it. A good move IMHO, but... (there
is always one, isn't there?)
...developers haven't really *flocked* to the different parts and the
small teams we all wanted to see haven't flourished. The 3.9 team ended
up acting more like harvesters than integrators. So the theory sounds
good - but the practice isn't following. Why is that so?
Perhaps it is simply because we haven't "pushed" this model enough in
the community. Are people aware that there now are different packages
waiting for Stewards to take them on? Are people aware of what that
means? Do we even have this model defined and described a little bit?
So that is surely one of the reasons. But is it really the only one - a
lack of "marketing"?
I think there is at least one more reason. I think that the simple fact
is that a lot of the work on the base packages are done as "side
effects". Things you stumble on while you are writing the next Seaside
or whatever. Things that have bugged you for a long time and suddenly
you just fire up a browser and try to fix it. Try to scratch that damn
At least bug fixes and small enhancements come about this way I am
pretty sure. So the same people that typically do these small fixes,
possibly all over the place, can't really sign up for each and every PI
of the image. And most of these people are also pretty busy so just
signing up for one of these PIs is a "step" that is easiest not taken.
Just looking at myself - yes, I want to help with IO, Collections, a few
tools and probably a bit here and there related to packages I try to
maintain. And yes, I did join the IO team when this was fresh - but
alas, even *I* have dozed off.
So if the vision of "permanent" teams around a Steward for specific
parts of the image fails because of the fact that people aren't that
focused or have that amount of time or interest (or whatever the reason
is) - are there other ways to organize ourselves?
I don't have a clear "package" to offer. :) But I do think we can fix
some problems at least:
1. The Easy Contribution.
Now, is it *easy* for someone to "share" a fix or enhancement? Is it a
single button to push? Is it obvious how to do it? Can a newbie do it?
Is the mental barrier low enough or is sharing a fix connected with a
bunch of prerequisites like code quality, unit tests etc that makes it
seem "hard work" to do it? Have you ever skipped sending in a fix
because it just felt like a bit too much work at the moment you made the
fix? Truthfully? :)
Earlier it was kinda easy. You picked the changesorter, sliced out your
fix, wrote a preamble and fired it off with a "mail to list". You knew
that perhaps it would not be picked up, perhaps not - but at least this
first step was easy. And yes, we drowned in such contributions and
suffered from lack of harvesting - but that is still the second step -
the first step seemed to work pretty ok.
Today it is *almost* as easy. We still use changesets for fixes etc, but
we upload to a Mantis installation instead. It gives better tracking and
so on, but the steps to create an issue etc is more complex. You need to
get an account and figure out what to write in various fields and so on.
But sure, it is still fairly easy. I bet we could make it even easier
2. The Bleeding Edge.
Today we really don't have a bleeding edge. This is an idea that has
been around in various shapes and forms, a separate alpha update stream
or whatever. This is also what most other "more conventional" OSS
projects have - the CVS/SVN or whatever repository. The classic model is
to have trusted developers that can just "commit" straight onto a
bleeding edge - and then it gets gradually frozen, tested, distilled,
reviewed or whatever when the times come for a release.
Our corresponding bleeding edge today would be a range of MC repos which
you would need to track and manually pull snapshots from - for each
package in the image. There are many. And the snapshots typically
interdepend on each other so you just can't pull the latest from them
I bet that if we had the official image available in a similarly "easy"
way as a single CVS/SVN repo - it would be much easier for developers to
engage. Doesn't this idea go against the partitioning idea? Yeah,
probably. But perhaps we can make them live side by side!
Consider if we just set such a thing up and let developers "go wild".
The maintainers of each separate piece could then track this thing and
"shout" if they saw something go astray. Or simply roll back or "fix"
changes that missed the mark. And they could then take "sanctioned"
snapshots of their each package and put that in a repo.
Ok, this email is FAAAR too long already. I did have a number 3 too -
but it is still a bit vague so I will stop here.
More information about the Squeak-dev