release prioritization

Craig Latta craig.latta at
Fri Feb 28 11:45:14 UTC 2003

Hi Hannes--

> Not having a proper test culture in Squeak leads us to have this kind
> of funny discussions.

	Perhaps you could elaborate as to what you consider a proper test
culture. In the meantime, I think we do have a constructive process. In
particular, we decided we wanted to make a release which supported
SqueakMap. We did this, we tested it, and now we're going to release it.

> Measuring risk just with a feeling in the guts?

	No; I think Doug is measuring risk by estimating the impact of leaving
out changes on the system's likely audience.

> "I feel like releaseing... I'm scary of metaclasses ....people don't use them anyway...".

	No one said that. :)

> But there is no idea if a release is better then an old one on the
> existing stuff or not.

	It's my understanding that we're gradually building up unit tests for
the entire system. We're making progress. We're not there yet, but I
don't think it should hold up releases, especially minor ones.

> For me 3.4  will be a "release" which is not proper Smalltalk (in
> the sense of the last 20 years) as it breaks in a fundamental way
> without the fix by Andreas.

	There are many other fundamental bugs in the system, several of which
have been in the system for many years. The assertion is that their
impact on the usability of 3.4, particularly on its new functionality
(SqueakMap), is low.

> He really has done an *excellent job*. And the test case he
> provided in just 30 minutes is wonderful! And the
> community is not able to verify his fix in 3 days ??

	I don't think anyone disputes the quality and verification of Andreas'
fix. But the actual act of incorporating it into a release, and testing
for errors that occur during that act, take time. Given the relatively
low impact of that bug (even though that part of the system is indeed
fundamental), there seems to be no disadvantage in deferring the fix to

	It seems to me that we were getting bogged down with a "just one more"
mentality. Yes, a particular fix may take add three days to a release
cycle, but these delays add up. For me, the delays make the Squeak
project markedly less satisfying. Right now, I'd like to be able to tell
newcomers "take a look at Squeak from" and know that they'll
get a release with SqueakMap support.

> The 3.4 release was planned for the end of 2002. No we are two month
> later.

	Four, actually. :)

> I wonder where this time pressure comes from?

	Obviously, since this is a volunteer effort, there is no direct time
pressure. Rather than time pressure, I think there is motivation; in
this case, a motivation to support SqueakMap in the release that most
newcomers will use. I also think it'd be good for us as a community to
develop expeditious release skills. In my opinion, we were overrating
the importance of several features and fixes with regard to the release

> On the other side at least some customers do not want a buggy 3.4.

	Again, I posit that relatively few people are likely to encounter the
bug to which you refer, and those who do will be eminently capable and
motivated to ge the fix. If you disagree, let's hear your rationale.

	As you mentioned, the stakes are relatively low. I'm surprised that
you're so upset at deferring the rest of the fixes. This is a minor
release (3.x). I'd certainly like to be more conservative with release
4, but the sorts of fixes we're discussing now are what minor releases
are for.

> On the other side this discussion about "releases" is in some
> sense a non issue as probably in the future we will have
> different configurations which will be packed for various
> target groups and automatically tested before releasing.

	Indeed. In fact, I think eventually the release artifact will be
laughably tiny.

> I could live with the idea of a buggy 3.4 if 3.5 for example
> is planned for doing in two months time. Then 3.4 would
> just be some kind of intermediary release.

	Precisely. :)

> The heading speaks of "priorization". Where are
> the plans for future releases? Non-existant!

	Clearly, then, now is the time to make the schedule. If you have
suggestions, let's hear them. Remember that Squeak has never really had
a priori feature/fix schedules before. I'm all for them.

> Is there a check list what 3.4 should be?

	Yes. It was verbalized at the Squeak BOF at OOPSLA 2002, then discussed
on the list, where consensus was (seemingly) achieved. The checklist
consisted simply of "SqueakMap support".

> You guides, please do your homework!

	This stuff needs to be done via public discussion; I don't think it's
appropriate for the guides to come up with it by themselves.


p.s. I'm not even going to touch the Microsoft comments. ;)

Craig Latta
improvisational musical informaticist
craig at
Smalltalkers do: [:it | All with: Class, (And love: it)]

More information about the Squeak-dev mailing list