[Squeakfoundation]re: release prioritization (was "ClassBuilder
roel.wuyts at iam.unibe.ch
Fri Feb 28 08:55:52 UTC 2003
Somebody needs to decide what is a release and what's get in there, and
it was decided that these were the Guides. I trust them to do an
excellent job at this, that is why they are responsible. I can imagine
that there is some 'bigger plan' for which they want to have this
release. The question for me is: 'what is this bigger plan'. If it is
only that it was promised to have a new release by a certain time, then
I agree with you that we can wait. But I guess the plan for 3.4 was to
have SM up and running, and that is also important to get out so that
everybody can enjoy it. Delaying this for one fix (that I find terribly
annoying but many people probably not) when there is a good working
update mechanism is probably not that bad.
PS: Personally I don't see a problem with Andreas' fix, and I would
just include it if the tests run and look good (which they do). But
then again there's also no problem in putting it in the update stream.
Then you and me and other people will work with an updated 3.4: no big
On Friday, February 28, 2003, at 08:37 AM, Hannes Hirzel wrote:
> Hi Doug
> Doug Way <dway at riskmetrics.com> wrote:
>> Okay, I'm very easily talked out of delaying the 3.4 release any
>> further :-) (and was having second thoughts after posting that last
>> message), so I agree with the prevailing opinion to leave this change
>> out and go ahead with the release.
> Well of course you guides can do anything you want "releasing" things,
> i.e. putting a label on a jar and call it a "release". Not having a
> proper test culture in Squeak leads us to have this kind of funny
> Measuring risk just with a feeling in the guts? "I feel like
> I'm scary of metaclasses ....people don't use them anyway...".
> Releaseing something at the moment just means that enough new
> features have been added and the guides feel that people have not been
> complaining too much about new bugs. But there is no idea if a release
> is better then an old one on the existing stuff or not.
> Be assured the first thing I will do after downloading your release
> is to include the fix of Andreas and already I will not work on
> your "release" anymore. And many of the list members will
> just do the same. For me 3.4 will be a "release" which
> is not proper Smalltalk (in the sense of the last 20 years) as it
> in a fundamental way without the fix by Andreas.
> 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 wonder where this time pressure comes from? The 3.4 release
> was planned for the end of 2002. No we are two month later.
> So what? Are customers pressing somewhere? In fact that
> would be good. On the other side at least some customers
> do not want a buggy 3.4.
> MS projects often get delayed much longer and with the .NET
> initiative (an approach with a VM as well!) they want to do it
> "right", even if that causes delays!
> Again: where is the time pressure? There a good releases and
> Hannes Hirzel
> P.S. 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.
> 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.
> P.S. 2 The heading speaks of "priorization". Where are
> the plans for future releases? Non-existant!
> Is there a check list what 3.4 should be? I didn't
> find it yet although as a member of the documentation
> team I had surfed a lot over the existing Squeak
> web pages and I was active at the mailing list.
> You guides , please do your homework!
Roel Wuyts Software
roel.wuyts at iam.unibe.ch University of Bern,
Board Member of the European Smalltalk User Group: www.esug.org
More information about the Squeak-dev