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 3.5a.
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 squeak.org" 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 schedule.
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.
-C
p.s. I'm not even going to touch the Microsoft comments. ;)
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
squeakfoundation@lists.squeakfoundation.org