Discussion:
Outstanding 3.4 bugs?
(too old to reply)
Andreas Raab
2012-01-28 11:21:04 UTC
Permalink
Hi Ned,

> These bugs (and more, like the much-discussed bug with adding an
> instVar to ClassDescription) still exist in 3.4g.

Here's an update on this problem. I could trace it down to a very obscure
breakage of the superclass/subclass invariant which can only happen when you
recompile any of the essential behaviors (Behavior, ClassDescription,
Class).

The short version of it is that ClassBuilder assumes it can see all the
subclasses of some class (this is obviously required since if it doesn't
then things will break horribly as instances of some classes are being
reshaped and others aren't). [*] However, during the "main mutation process"
ClassBuilder removes the class to reshape from its (old) superclass and
later puts back under the new superclass. So far so good.

Except that when we recompile the meta classes, we actually use the
non-metaclass hierarchy for determining the subclasses of some metaclass
(e.g., the subclasses of meta class "Foo class" are the meta classes of
Foo's subclasses "Foo subclasses collect:[:each| each class]").

This leads to an "interesting" effect when we recompile any of the
aforementioned behaviors. When we recompile (for example) ClassDescription
we recompile all the subclasses of Class (the meta class hierarchy) as well.
However, at the time when we recompile "Behavior class" we don't see
"ClassDescription class" as one of its subclasses - because while
recompiling we have removed ClassDescription from its superclass (Behavior).
Duh...

So I actually tried to simply "remove the removal" but apparently that's not
quite enough. I haven't had the time to go beyound this but it is clear that
the problem we are seeing is an (accidental) breaking of the
superclass/subclass invariant (when you look at the errors real close you
can see that it is caused by a meta class which wasn't reshaped).

[*] Because of the importance of the superclass/subclass invariant I
actually think that #addSubclass: and #removeSubclass: should really be
private messages. To me these look "just like the others" but using those
without knowing what you do means you're going to break the system a _long_
time after you did it. Similarly with "Class new" or any of these messages -
they ought to be screened and either raise errors or do something sensible.

So at this point it is clear what is causing the problem and at least what
part of the solution must be - namely _strict_ adherence to the
superclass/subclass invariant.

BTW, forget about everything I wrote in that other message. It's plain
nonsense. This happens to me all the time when I start to think "meta" and
get myself messed up with "an instance being the class of its class". That
all works perfectly well as it should.

Cheers,
- Andreas
Brent Vukmer
2012-01-28 11:21:04 UTC
Permalink
Andreas --

How did you debug this? I remember you saying to Ned that his stack
trace didn't go down far enough to get to the problem..

-----Original Message-----
From: Andreas Raab [mailto:***@gmx.de]
Sent: Thursday, February 27, 2003 4:04 PM
To: 'Discussing the Squeak Foundation'
Cc: squeak-***@lists.squeakfoundation.org
Subject: RE: Outstanding 3.4 bugs?


Hi Ned,

> These bugs (and more, like the much-discussed bug with adding an
> instVar to ClassDescription) still exist in 3.4g.

Here's an update on this problem. I could trace it down to a very
obscure
breakage of the superclass/subclass invariant which can only happen when
you
recompile any of the essential behaviors (Behavior, ClassDescription,
Class).
Andreas Raab
2012-01-28 11:21:04 UTC
Permalink
> How did you debug this? I remember you saying to Ned that his stack
> trace didn't go down far enough to get to the problem..

Well, I recreated the problem, saw that the error you get was a recursive
one, deduced that it must be happening in ContextPart>>printOn: put an
exception handler in there to simply print "<error>" (this might actually be
generally helpful) and then I could see that the problem originated from
Metaclass>>name which apparently tried to concatenate a Dictionary with a
String. Evaluating "thisClass instVarAt: ..." in the debugger (since you
can't inspect it) showed me that the values of every instVar were shifted by
one from what it should be which is the exact effect you see when you
"forget" to reshape a subclass of some other class. From there, you can
start hacking ClassBuilder - I put a halt in there if some class' name
wasn't a stringy object. That showed me the "first place where the problem
occurs" - e.g., the last class after which it gets broken. In this halt you
see that (and which) the meta classes are broken and the stack tells you the
rest of the story.

Cheers,
- Andreas

>
> -----Original Message-----
> From: Andreas Raab [mailto:***@gmx.de]
> Sent: Thursday, February 27, 2003 4:04 PM
> To: 'Discussing the Squeak Foundation'
> Cc: squeak-***@lists.squeakfoundation.org
> Subject: RE: Outstanding 3.4 bugs?
>
>
> Hi Ned,
>
> > These bugs (and more, like the much-discussed bug with adding an
> > instVar to ClassDescription) still exist in 3.4g.
>
> Here's an update on this problem. I could trace it down to a very
> obscure
> breakage of the superclass/subclass invariant which can only
> happen when
> you
> recompile any of the essential behaviors (Behavior, ClassDescription,
> Class).
>
>
Andreas Raab
2012-01-28 11:21:04 UTC
Permalink
Okay, restating the problem actually helped me to understand how to fix it.

"Change Set: MetaClassBuilderFix
Date: 27 February 2003
Author: Andreas Raab

This change set fixes a rather obscure bug with reshaping the entire class
hierarchy from ClassBuilder. The problem was introduced by accidentally
breaking the superclass/subclass invariant. The CS fixes this problem, by
doing so actually removes some code and documents the critical invariants
(both by putting comments into the methods affected and by making those
methods private which temporarily break the crucial invariants).

The class comment has been extended to document the fundamental assumption
that ClassBuilder needs access to ALL of the subclasses no matter where no
matter how they are created.
"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MetaClassBuilderFix.cs.gz
Type: application/x-gzip
Size: 4540 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030227/283ed65c/MetaClassBuilderFix.cs.bin
Doug Way
2012-01-28 11:21:05 UTC
Permalink
A general question: Do you think this fix looks reasonably safe enough to
include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add
this, we would need to postpone the release by a few days at least to test
this a bit. On the other hand, this is a sort-of important fix which may be
worth delaying 3.4 by a few days.

If we added this, I would probably create a quickie 3.4gammaTwo, and I would
encourage people to do some class-rebuilding related testing on it.

- Doug Way


Andreas Raab wrote:
>
> Okay, restating the problem actually helped me to understand how to fix it.
>
> "Change Set: MetaClassBuilderFix
> Date: 27 February 2003
> Author: Andreas Raab
>
> This change set fixes a rather obscure bug with reshaping the entire class
> hierarchy from ClassBuilder. The problem was introduced by accidentally
> breaking the superclass/subclass invariant. The CS fixes this problem, by
> doing so actually removes some code and documents the critical invariants
> (both by putting comments into the methods affected and by making those
> methods private which temporarily break the crucial invariants).
>
> The class comment has been extended to document the fundamental assumption
> that ClassBuilder needs access to ALL of the subclasses no matter where no
> matter how they are created.
> "
>
> ------------------------------------------------------------------------------
> Name: MetaClassBuilderFix.cs.gz
> MetaClassBuilderFix.cs.gz Type: ChangeSet (application/x-unknown-content-type-cs_auto_file)
> Encoding: base64
>
> ------------------------------------------------------------------------------
Tim Rowledge
2012-01-28 11:21:05 UTC
Permalink
Doug Way <***@riskmetrics.com> wrote:

>
> A general question: Do you think this fix looks reasonably safe enough to
> include with 3.4gamma?
The question one should be asking at this stage is more along the lines
of "do I absolutely, positively _have_ to fix this right now and am I
absolutely, positively able to confirm it doesn't break anything?" than
"does it look about right?".

3.4 is already very much later than we originally intended and I suggest
that we release it and have Andreas' fix available in the update stream
asap. Bug fixes are, after all, what that is for. If neccessary the
traits and islands packages could include it.

Let's release.

tim

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Never write software that anthropomorphizes the machine. They hate that.
Craig Latta
2012-01-28 11:21:05 UTC
Permalink
(Resent to squeak-dev, since my email address wasn't set right for
squeak-dev's anti-spam processor before.)

Colin writes:

> I think it would be worth delaying the release of 3.4 to include this
> fix. Having easy-to-install packages for Traits and Islands would be
> very beneficial. The more people can play around with and exercise
> that code, the better.

I don't think that's a convincing rationale for inclusion in
3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems
which have a catastrophic effect on a newcomer's ability to use
SqueakMap should delay 3.4.

Doug writes (on the Foundation list):

> ...since Andreas just posted the ClassBuilder fix, I'm thinking that
> may be worth including and postponing the release by a few days for
> people to test.

Why? (And I don't use question marks lightly in this message,
since I know they could cause more delay. :)

> Since I'm doing that, I could also perhaps include Ned's recent
> ArchiveViewer fix, since I've looked at that and its seems
> straightforward and is a somewhat important fix.

(:

I don't think "somewhat important" cuts it at this release
stage. Instead, I think it's better to weigh the results of leaving
something
out, rather than of including it.

My recollection of our group discussions at OOPSLA, in November
2002, were that we would take 3.2, add SqueakMap support to it, and
release it as 3.4. It is now February 2003. This surprises me, even
given our history. :)

I think we should release 3.4 now, and defer all outstanding
available fixes into the 3.5a stream (subject to harvester approval). In
our current situation, I think anyone likely to encounter the bugs
described recently will be able to get them easily from the update
stream. In the meantime, newcomers will have easier access to SqueakMap
sooner. I think it's time to release.

thanks,

-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
Ned Konz
2012-01-28 11:21:05 UTC
Permalink
On Thursday 27 February 2003 06:07 pm, Craig Latta wrote:
> > Since I'm doing that, I could also perhaps include Ned's recent
> > ArchiveViewer fix, since I've looked at that and its seems
> > straightforward and is a somewhat important fix.
>
> (:
>
> I don't think "somewhat important" cuts it at this release
> stage. Instead, I think it's better to weigh the results of leaving
> something
> out, rather than of including it.

If someone loads SqueakMap, they get SARInstaller. And then they get
the fix.

So it's only people who *don't* get SqueakMap loaded into their images
who are even going to see this problem.

I'd say:

RELEASE!

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Craig Latta
2012-01-28 11:21:07 UTC
Permalink
Colin writes:

> I think it would be worth delaying the release of 3.4 to include this
> fix. Having easy-to-install packages for Traits and Islands would be
> very beneficial. The more people can play around with and exercise
> that code, the better.

I don't think that's a convincing rationale for inclusion in 3.4. The
3.4 release is a vehicle for SqueakMap. I think only problems which have
a catastrophic effect on a newcomer's ability to use SqueakMap should
delay 3.4.

Ned writes (on the Foundation list):

> ...since Andreas just posted the ClassBuilder fix, I'm thinking that
> may be worth including and postponing the release by a few days for
> people to test.

Why? (And I don't use question marks lightly in this message, since I
know they could cause more delay. :)

> Since I'm doing that, I could also perhaps include Ned's recent
> ArchiveViewer fix, since I've looked at that and its seems
> straightforward and is a somewhat important fix.

(:

I don't think "somewhat important" cuts it at this release stage.
Instead, I think it's better to weigh the results of leaving something
out, rather than of including it.

My recollection of our group discussions at OOPSLA, in November 2002,
were that we would take 3.2, add SqueakMap support to it, and release it
as 3.4. It is now February 2003. This surprises me, even given our
history. :)

I think we should release 3.4 now, and defer all outstanding available
fixes into the 3.5a stream (subject to harvester approval). In our
current situation, I think anyone likely to encounter the bugs described
recently will be able to get them easily from the update stream. In the
meantime, newcomers will have easier access to SqueakMap sooner. I think
it's time to release.


thanks,

-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta
2012-01-28 11:21:07 UTC
Permalink
I wrote:

> Ned writes (on the Foundation list)...

Oops, sorry, that was Doug.


-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
Brent Vukmer
2012-01-28 11:21:05 UTC
Permalink
Thanks Andreas. BTW, I just finished creating a Swiki page documenting
the problem ( http://minnow.cc.gatech.edu/squeak/3058 )! Obviously this
won't be a "known bug" for 3.4, if this fix is accepted.. :)

-----Original Message-----
From: Andreas Raab [mailto:***@gmx.de]
Sent: Thursday, February 27, 2003 5:50 PM
To: 'The general-purpose Squeak developers list'
Subject: [FIX] ClassBuilder problem


Okay, restating the problem actually helped me to understand how to fix
it.

"Change Set: MetaClassBuilderFix
Date: 27 February 2003
Author: Andreas Raab

This change set fixes a rather obscure bug with reshaping the entire
class
hierarchy from ClassBuilder. The problem was introduced by accidentally
breaking the superclass/subclass invariant. The CS fixes this problem,
by
doing so actually removes some code and documents the critical
invariants
(both by putting comments into the methods affected and by making those
methods private which temporarily break the crucial invariants).

The class comment has been extended to document the fundamental
assumption
that ClassBuilder needs access to ALL of the subclasses no matter where
no
matter how they are created.
"
Brent Vukmer
2012-01-28 11:21:05 UTC
Permalink
Andreas --

Is the SUnit test that Hannes submitted, sufficient -- do you have any
others you'd like to add?

'From Squeak3.2 of 11 July 2002 [latest update: #4956] on 24 February
2003 at 4:22:07 pm'!
TestCase subclass: #BCCMaddInstVar
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'SUnit-Tests'!


!BCCMaddInstVar methodsFor: 'as yet unclassified' stamp: 'hjh 2/24/2003
14:49'!
test03AddInstanceVarToClassDescription

self assert: (ClassDescription isKindOf: ClassDescription).
self assert: (Object isKindOf: Object).
self deny: (OrderedCollection isKindOf: OrderedCollection).

ClassDescription addInstVarName: 'myAdditionalInstVar'.

ClassDescription removeInstVarName: 'myAdditionalInstVar'.! !

-----Original Message-----
From: Andreas Raab [mailto:***@gmx.de]
Sent: Thursday, February 27, 2003 5:50 PM
To: 'The general-purpose Squeak developers list'
Subject: [FIX] ClassBuilder problem


Okay, restating the problem actually helped me to understand how to fix
it.

"Change Set: MetaClassBuilderFix
Date: 27 February 2003
Author: Andreas Raab

This change set fixes a rather obscure bug with reshaping the entire
class
hierarchy from ClassBuilder. The problem was introduced by accidentally
breaking the superclass/subclass invariant. The CS fixes this problem,
by
doing so actually removes some code and documents the critical
invariants
(both by putting comments into the methods affected and by making those
methods private which temporarily break the crucial invariants).

The class comment has been extended to document the fundamental
assumption
that ClassBuilder needs access to ALL of the subclasses no matter where
no
matter how they are created.
"
Andreas Raab
2012-01-28 11:21:05 UTC
Permalink
> Is the SUnit test that Hannes submitted, sufficient -- do you have any
> others you'd like to add?

I've attached a few which might be helpful.

Cheers,
- Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kernel-Tests-ClassBuilder.st
Type: application/octet-stream
Size: 5535 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030228/b29a3385/Kernel-Tests-ClassBuilder.obj
Andreas Raab
2012-01-28 11:21:05 UTC
Permalink
Doug,

This isn't for me to decide. Of course, *I* think that it works, but I
thought so before and I was wrong ;-( I'll (happily ;) leave this decision
to the guides.

Cheers,
- Andreas

> -----Original Message-----
> From: Doug Way [mailto:***@riskmetrics.com]
> Sent: Friday, February 28, 2003 1:07 AM
> To: The general-purpose Squeak developers list; Andreas Raab
> Subject: Re: [FIX] ClassBuilder problem
>
>
>
> A general question: Do you think this fix looks reasonably
> safe enough to
> include with 3.4gamma? I was going to finalize 3.4 by
> tomorrow, but if we add
> this, we would need to postpone the release by a few days at
> least to test
> this a bit. On the other hand, this is a sort-of important
> fix which may be
> worth delaying 3.4 by a few days.
>
> If we added this, I would probably create a quickie
> 3.4gammaTwo, and I would
> encourage people to do some class-rebuilding related testing on it.
>
> - Doug Way
>
>
> Andreas Raab wrote:
> >
> > Okay, restating the problem actually helped me to
> understand how to fix it.
> >
> > "Change Set: MetaClassBuilderFix
> > Date: 27 February 2003
> > Author: Andreas Raab
> >
> > This change set fixes a rather obscure bug with reshaping
> the entire class
> > hierarchy from ClassBuilder. The problem was introduced by
> accidentally
> > breaking the superclass/subclass invariant. The CS fixes
> this problem, by
> > doing so actually removes some code and documents the
> critical invariants
> > (both by putting comments into the methods affected and by
> making those
> > methods private which temporarily break the crucial invariants).
> >
> > The class comment has been extended to document the
> fundamental assumption
> > that ClassBuilder needs access to ALL of the subclasses no
> matter where no
> > matter how they are created.
> > "
> >
> >
> --------------------------------------------------------------
> ----------------
> > Name: MetaClassBuilderFix.cs.gz
> > MetaClassBuilderFix.cs.gz Type: ChangeSet
> (application/x-unknown-content-type-cs_auto_file)
> > Encoding: base64
> >
> >
> --------------------------------------------------------------
> ----------------
>
Colin Putney
2012-01-28 11:21:05 UTC
Permalink
On Thursday, February 27, 2003, at 04:07 PM, Doug Way wrote:

>
> A general question: Do you think this fix looks reasonably safe
> enough to
> include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but
> if we add
> this, we would need to postpone the release by a few days at least to
> test
> this a bit. On the other hand, this is a sort-of important fix which
> may be
> worth delaying 3.4 by a few days.
>
> If we added this, I would probably create a quickie 3.4gammaTwo, and I
> would
> encourage people to do some class-rebuilding related testing on it.

I think it would be worth delaying the release of 3.4 to include this
fix. Having easy-to-install packages for Traits and Islands would be
very beneficial. The more people can play around with and exercise that
code, the better.

Colin Putney
Whistler.com
Doug Way
2012-01-28 11:21:05 UTC
Permalink
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.

The Traits and Islands packages for 3.4 can include Andreas' fix as
part of their install, which shouldn't significantly hinder people from
exercising that code... those packages are both pretty experimental
anyway.

- Doug Way


On Thursday, February 27, 2003, at 08:59 PM, Craig Latta wrote:

> Colin writes:
>
>> I think it would be worth delaying the release of 3.4 to include this
>> fix. Having easy-to-install packages for Traits and Islands would be
>> very beneficial. The more people can play around with and exercise
>> that code, the better.
>
> I don't think that's a convincing rationale for inclusion in 3.4. The
> 3.4 release is a vehicle for SqueakMap. I think only problems which
> have
> a catastrophic effect on a newcomer's ability to use SqueakMap should
> delay 3.4.
>
> Doug writes (on the Foundation list):
>
>> ...since Andreas just posted the ClassBuilder fix, I'm thinking that
>> may be worth including and postponing the release by a few days for
>> people to test.
>
> Why? (And I don't use question marks lightly in this message, since I
> know they could cause more delay. :)
>
>> Since I'm doing that, I could also perhaps include Ned's recent
>> ArchiveViewer fix, since I've looked at that and its seems
>> straightforward and is a somewhat important fix.
>
> (:
>
> I don't think "somewhat important" cuts it at this release stage.
> Instead, I think it's better to weigh the results of leaving something
> out, rather than of including it.
>
> My recollection of our group discussions at OOPSLA, in November 2002,
> were that we would take 3.2, add SqueakMap support to it, and release
> it
> as 3.4. It is now February 2003. This surprises me, even given our
> history. :)
>
> I think we should release 3.4 now, and defer all outstanding available
> fixes into the 3.5a stream (subject to harvester approval). In our
> current situation, I think anyone likely to encounter the bugs
> described
> recently will be able to get them easily from the update stream. In the
> meantime, newcomers will have easier access to SqueakMap sooner. I
> think
> it's time to release.
>
>
> thanks,
>
> -C
>
> --
> Craig Latta
> improvisational musical informaticist
> ***@netjam.org
> www.netjam.org/resume
> Smalltalkers do: [:it | All with: Class, (And love: it)]
> _______________________________________________
> Squeakfoundation mailing list
> ***@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
goran.hultgren at bluefish.se ()
2012-01-28 11:21:13 UTC
Permalink
Hi all!

Just wanted to chip in and agree we should release - I read through the
discussion and agree that these aren't showstoppers. Hey, I am playing
catch up with my inbox - who knows, we might already have released. :-)

Sidenote: Making automated "releases" like the first every month is IMHO
not a "release". That is more like a nightly build. The release isn't a
release just because we say it is - it is a release because we have been
going through the alpha/beta/gamma phases. Doing that in one month
doesn't sound useful to me.

But I agree that we can try to make some form of regular schedule for
the releases. 2 per year sounds reasonable to me (just a hipshot).

regards, Göran
Roel Wuyts
2012-01-28 11:21:05 UTC
Permalink
Yes, exactly. Let's get this 3.4! Gives us some time to exercise the
fix (Nathanael will look at it more or less straight away anyway).

On Friday, February 28, 2003, at 05:19 AM, Doug Way 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.
>
> The Traits and Islands packages for 3.4 can include Andreas' fix as
> part of their install, which shouldn't significantly hinder people
> from exercising that code... those packages are both pretty
> experimental anyway.
>
> - Doug Way
>
>
> On Thursday, February 27, 2003, at 08:59 PM, Craig Latta wrote:
>
>> Colin writes:
>>
>>> I think it would be worth delaying the release of 3.4 to include this
>>> fix. Having easy-to-install packages for Traits and Islands would be
>>> very beneficial. The more people can play around with and exercise
>>> that code, the better.
>>
>> I don't think that's a convincing rationale for inclusion in 3.4. The
>> 3.4 release is a vehicle for SqueakMap. I think only problems which
>> have
>> a catastrophic effect on a newcomer's ability to use SqueakMap should
>> delay 3.4.
>>
>> Doug writes (on the Foundation list):
>>
>>> ...since Andreas just posted the ClassBuilder fix, I'm thinking that
>>> may be worth including and postponing the release by a few days for
>>> people to test.
>>
>> Why? (And I don't use question marks lightly in this message, since I
>> know they could cause more delay. :)
>>
>>> Since I'm doing that, I could also perhaps include Ned's recent
>>> ArchiveViewer fix, since I've looked at that and its seems
>>> straightforward and is a somewhat important fix.
>>
>> (:
>>
>> I don't think "somewhat important" cuts it at this release stage.
>> Instead, I think it's better to weigh the results of leaving something
>> out, rather than of including it.
>>
>> My recollection of our group discussions at OOPSLA, in November 2002,
>> were that we would take 3.2, add SqueakMap support to it, and release
>> it
>> as 3.4. It is now February 2003. This surprises me, even given our
>> history. :)
>>
>> I think we should release 3.4 now, and defer all outstanding
>> available
>> fixes into the 3.5a stream (subject to harvester approval). In our
>> current situation, I think anyone likely to encounter the bugs
>> described
>> recently will be able to get them easily from the update stream. In
>> the
>> meantime, newcomers will have easier access to SqueakMap sooner. I
>> think
>> it's time to release.
>>
>>
>> thanks,
>>
>> -C
>>
>> --
>> Craig Latta
>> improvisational musical informaticist
>> ***@netjam.org
>> www.netjam.org/resume
>> Smalltalkers do: [:it | All with: Class, (And love: it)]
>> _______________________________________________
>> Squeakfoundation mailing list
>> ***@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>
>
Roel Wuyts Software
Composition Group
***@iam.unibe.ch University of Bern,
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org
Hannes Hirzel
2012-01-28 11:21:05 UTC
Permalink
Hi Doug

Doug Way <***@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 discussions.
Measuring risk just with a feeling in the guts? "I feel like
releaseing...
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 breaks

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
others.


Regards
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!
Craig Latta
2012-01-28 11:21:06 UTC
Permalink
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
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
Doug Way
2012-01-28 11:21:08 UTC
Permalink
Hannes Hirzel wrote:
>
> Hi Doug
>
> Doug Way <***@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 discussions.
> Measuring risk just with a feeling in the guts? "I feel like
> releaseing...
> I'm scary of metaclasses ....people don't use them anyway...".

Well, the way I phrased it ("I'm very easily talked out of delaying the 3.4
release...") may have made it seem that I suddenly decided to go ahead with
the release on a whim.

But that's not really the case. I (and the other Guides) believe that leaving
this fix out is the right thing to do at this stage of the release. We do
have some (admittedly rough) standards that we're trying to follow during the
release cycle. See: http://swiki.squeakfoundation.org/squeakfoundation/89

3.4 is currently in "gamma" status, which is basically a candidate final
release, and that means that only critical problems should hold up the
release. It's hard to define "critical" precisely, but it would have to be
something that made the system unusable to a large portion of users. The
ClassBuilder problem is significant, but would really only affect people who
need to rebuild all of their classes, which is only required by a few
(relatively experimental) packages.

And there may be significant risk in adding this fix to 3.4 at this late
stage... changing the ClassBuilder is a pretty fundamental change. It might
have some subtle side effect on the way classes are made obsolete, I don't
know. I'm sure Andreas would not absolutely guarantee that it is
side-effect-free. :-) So, even allowing 3 days to test this sort of change
might not be enough.

Anyway, these are typical issues for any software release. At some point you
do have to decide that enough changes/fixes have gone into a particular
release, and we need to put the remaining larger changes/fixes into the next
release. I was starting to fall into the "just one more fix" trap myself
here.

Of course there needs to be an overall plan, too, which we roughly adhered to
for 3.4, although the final release date is now quite late for various
reasons, mostly related to the Guides taking over responsibility from SqC.
(We are new at this, after all.)

Regarding 3.5 content, I agree that that needs to be discussed... I imagine
discussions will start up on that topic soon on the SqF list. (Ah, I see you
just started a thread here on squeak-dev...)

- Doug Way
Hannes Hirzel
2012-01-28 11:21:06 UTC
Permalink
Doug Way <***@riskmetrics.com> wrote:
> A general question: Do you think this fix looks reasonably safe enough to
> include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add
> this, we would need to postpone the release by a few days at least to test
> this a bit.

Postponing? Yes!

On the other hand, this is a sort-of important fix which may be
> worth delaying 3.4 by a few days.

You put it excellently!

-- Hannes
Roel Wuyts
2012-01-28 11:21:06 UTC
Permalink
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
deal really.

On Friday, February 28, 2003, at 08:37 AM, Hannes Hirzel wrote:

>
> Hi Doug
>
> Doug Way <***@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
> discussions.
> Measuring risk just with a feeling in the guts? "I feel like
> releaseing...
> 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
> breaks
>
> 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
> others.
>
>
> Regards
> 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
Composition Group
***@iam.unibe.ch University of Bern,
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org
Hannes Hirzel
2012-01-28 11:21:06 UTC
Permalink
Roel Wuyts <***@iam.unibe.ch> wrote:
> 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.

Yes, adding SM and not breaking existing things.


>From http://swiki.squeakfoundation.org/squeakfoundation/79
<citation>
3.4 -- The main purpose of this release is to create an up to date,
viable version, that's a good starting point to making Squeak more
modular and it's development more decentralized.

Changes:
- Includes non-modules related updates from 3.3a, including the dynamic
filelist services refactoring.
- An option to load the SqueakMap package catalog and the base Package
Loader from the net.
- A dynamic open menu so packages can now register there and become
first class applications.
- Refactorings making various parts of the image easily removable. See
Modularizing the Squeak image for the plan and status.
- Various other fixes have been included.

Release is tentatively set to end of 2002.
</citation>


Regarding "Refactoring making various packages easily removable":

There is just Balloon3DRemoval and GamesRemoval. I do not consider this
goal is met.


And breaking an important thing and not including the fix is surely not
good stewardship as well.


Again: Where does this time pressure at the expense of quality come
from?


Cheers
Hannes
Marcus Denker
2012-01-28 11:21:06 UTC
Permalink
On Fri, Feb 28, 2003 at 11:22:04AM +0100, Hannes Hirzel wrote:
>
> Regarding "Refactoring making various packages easily removable":
>
> There is just Balloon3DRemoval and GamesRemoval. I do not consider this
> goal is met.
>
I really don't think anyone intended to start this kind of refactoring
in 3.4: This is nothing you want to do in a beta stage! Refactoring
and cleaning is something for 3.5alpha.

But I think it would be good to have a last look at important bugfixes
to add to 3.4, though.

Marcus

--
Marcus Denker ***@ira.uka.de -- Squeak! http://squeak.de
goran.hultgren at bluefish.se ()
2012-01-28 11:21:13 UTC
Permalink
Hi all!

Hannes Hirzel <***@bluewin.ch> wrote:
[SNIP]
> >From http://swiki.squeakfoundation.org/squeakfoundation/79
> <citation>
> 3.4 -- The main purpose of this release is to create an up to date,
> viable version, that's a good starting point to making Squeak more
> modular and it's development more decentralized.
>
> Changes:
> - Includes non-modules related updates from 3.3a, including the dynamic
> filelist services refactoring.
> - An option to load the SqueakMap package catalog and the base Package
> Loader from the net.
> - A dynamic open menu so packages can now register there and become
> first class applications.
> - Refactorings making various parts of the image easily removable. See
> Modularizing the Squeak image for the plan and status.
> - Various other fixes have been included.
>
> Release is tentatively set to end of 2002.
> </citation>
>
>
> Regarding "Refactoring making various packages easily removable":
>
> There is just Balloon3DRemoval and GamesRemoval. I do not consider this
> goal is met.

Well, I think the goal there was to simply include those refactorings
that we got around to do.
Then later (I think) these refactorings instead got registered at SM and
we decided that actually performing them could wait for 3.5 - otherwise
we are potentially prolonging the relase by creating turmoil in the
image.

So... well, we can all argue about that goal - but personally I think it
was good that we didn't start to actually tear the image apart in 3.4
because I think it will be *hard work* and take *solid time and
commitment* to get it right. Lets do that in 3.5 now that we have a 3.4
that seems pretty good and has SM enabled from start. Newbies will
hopefully read the welcome text and find the link.

(and the fact that we intend to start breaking apart the image makes me
wonder if we can aim for a one-month release cycle as well - sounds darn
impossible to me)

> And breaking an important thing and not including the fix is surely not
> good stewardship as well.

And Hannes also wrote in another post:
> 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 discussions.
> Measuring risk just with a feeling in the guts? "I feel like
> releaseing...
> I'm scary of metaclasses ....people don't use them anyway...".

Hey, hold on a minute. I usually don't get upset but the above felt like
a blow below the belt.
Fact: We don't have a good test culture in Squeak yet.

Does this mean we should just give up? Of course not - we try to make it
work. There is something called alpha, beta, gamma which we try to use
and sure - it's not as cool as 14000 unit tests, I agree.

Does it mean we don't want a good test culture? NO. We all want it
(well, of course someone raises his hand at this point and says "I
don't" but whatever) and we are slowly moving into a module world where
tests will probably play a significant role in the future - *when they
have been written*.

It's life, things break. IMHO. Sure, if we had tons of tests etc etc it
wouldn't happen - but we don't yet.

Sidenote: Personally I am just thankful Doug and Scott have had the time
to push this release through.

> Again: Where does this time pressure at the expense of quality come
> from?

Well, there is pressure within the community to get 3.4 "nailed down" so
that people can start depending on it for their work. That is the only
pressure I am aware of but it is enough. Of course there is no pressure
from outside the community (as with most open source projects) - we
simply create the pressure ourselves.

IMHO it is all about setting a level of quality and then trying to reach
it within a reasonable time limit. If we are aiming for a perfect Squeak
then we would never be able to release because FIXes just keep
appearing... Thankfully. :-)

Anyway, I am also not sure we should be discussing an elaborate release
process until we know a bit more about how the future will look. Why?
Because the process should be anchored in packages and not the "old" way
of viewing the Squeak cosmos (the image). Packages can have clearly
separate life cycles and release processes - that is one of the big
points.

So I am a bit amazed that noone picked up the thread about that,
subjects:
"Package grouping (was SqueakMap vs Debian)"
"SqueakMap vs Debian"

So, please read those posts and apply your thoughts about a good release
process using tests on that kind of Debianish world. That is at least
what I would like to discuss.

regards, Göran

PS. I think it is imperative that we maintain the focus on packages and
distribution of maintenance responsibility of the core packages
(stewardship). The centralized approach simply doesn't scale enough.
Daniel Vainsencher
2012-01-28 11:21:06 UTC
Permalink
Hannes raised an important question - where does time pressure come
from?

He also raised another important question - why didn't we meet our
stated goals?

I think these are important enough, they deserve answering, not arguing
about them.

Time pressure comes from the nature and purpose of releases. One can say
that any image at all of Squeak, with any combinations of changesets
loaded, is a version of Squeak. What separates a release from any other
version is that it's visible. All of it's natural and most important
qualities come simply from that: it's rarity causes it to be visible.

It's important to remember that people measure the quality of an
implementation mostly by it's releases - not by fixes/packages that can
be loaded, because probably no two pair of people will apply the same
ones. This is meant to change when we have configurations, but that's
the way it is now.

What that means, is that right now, people measure us by 3.2. Most
everyone on the list knows of SM, and loaded it for their 3.2, or just
uses 3.4, which is nicely stable enough to load anything that doesn't
touch the core as Island or Traits do. So we don't suffer much from the
delay of this release. Or rather, not directly. Because newbies surely
do. To newbies, loading anything into Squeak is still quite complicated,
and the first thing they're likely to be told is not to use the official
release, but a development release.

That's a sign of a project that's not releasing often enough. If your
production and your development are very different, you stop feeling the
pains of the production, and you stop being aware of what your product
is like, and you focus on the wrong things.

If we have bugs (and we have more than just those handful that were
mentioned), the solution isn't to delay the release, it is to have SUnit
tests, use them, and keep them green. Think longer term - it's not about
making a perfect release - that'll always be a good excuse to delay a
little more. It's about having many releases, at quite frequent,
predictable intervals, that are getting better and better, and keeping
production and development close. That'll give us long term properties
that will keep Squeak getting better.

And no, I don't promise to never break anything that's worked before.
First, nobody's ever promised that, neither the previous regime, nor any
other maintainer except maybe Knuth. Second, the main technical benefit
of an open source project is parallelized testing/debugging. But that is
completely dependent on people actually doing it. Third, to promise
strictly monotone-improving releases, I'd need SUnit tests with every
change that gets submitted. Hmm :-)

Now, why didn't all of the refactorings get in? well, there's a page on
squeakfoundation swiki, devoted to the status of the intended
refactorings. They're almost all done and waiting for (come on, I'm sure
you know - ) testing. When people want to see them get in, they'll start
testing, and as soon as people tell their authors that they load, or
they don't load, or there's this problem or that or it's all very nice,
we can actually do the work of clearing them to get in the image. In
3.5, of course.

Why didn't we meet our goals? because the goals we stated and the
actions of the wider community were not in line. I'm not shocked - this
is a community, not an army unit. Also, the new "regime" is pretty new,
so us and said community are still getting used to each other. Having
alot of these releases, a time when emotions run high and soul searching
is popular, will make the adaptation go faster.

Daniel

Hannes Hirzel <***@bluewin.ch> wrote:
> Roel Wuyts <***@iam.unibe.ch> wrote:
> > 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.
>
> Yes, adding SM and not breaking existing things.
>
>
> >From http://swiki.squeakfoundation.org/squeakfoundation/79
> <citation>
> 3.4 -- The main purpose of this release is to create an up to date,
> viable version, that's a good starting point to making Squeak more
> modular and it's development more decentralized.
>
> Changes:
> - Includes non-modules related updates from 3.3a, including the dynamic
> filelist services refactoring.
> - An option to load the SqueakMap package catalog and the base Package
> Loader from the net.
> - A dynamic open menu so packages can now register there and become
> first class applications.
> - Refactorings making various parts of the image easily removable. See
> Modularizing the Squeak image for the plan and status.
> - Various other fixes have been included.
>
> Release is tentatively set to end of 2002.
> </citation>
>
>
> Regarding "Refactoring making various packages easily removable":
>
> There is just Balloon3DRemoval and GamesRemoval. I do not consider this
> goal is met.
>
>
> And breaking an important thing and not including the fix is surely not
> good stewardship as well.
>
>
> Again: Where does this time pressure at the expense of quality come
> from?
>
>
> Cheers
> Hannes
> _______________________________________________
> Squeakfoundation mailing list
> ***@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
Simon Michael
2012-01-28 11:21:07 UTC
Permalink
Daniel Vainsencher <***@netvision.net.il> writes:
> If we have bugs (and we have more than just those handful that were
> mentioned), the solution isn't to delay the release, it is to have SUnit
> tests, use them, and keep them green. Think longer term - it's not about
> making a perfect release - that'll always be a good excuse to delay a
> little more. It's about having many releases, at quite frequent,
> predictable intervals, that are getting better and better, and keeping
> production and development close. That'll give us long term properties
> that will keep Squeak getting better.

+1, well said.

I've found releasing on the first of every month to be a useful discipline.
What changes would be needed to make this practical for squeak, I wonder ?
Maybe none.

Thanks for your work, guides.
-Simon
Cees de Groot
2012-01-28 11:21:07 UTC
Permalink
On Fri, 2003-02-28 at 17:56, Simon Michael wrote:
> +1, well said.
>
seconded.

> I've found releasing on the first of every month to be a useful discipline.
> What changes would be needed to make this practical for squeak, I wonder ?
> Maybe none.
>
Yup - we've taken to release an RC every Thursday at 13:30, and when no
showstoppers have been found by Friday 18:00, it is moved into
production. I think a similar time regime could put the necessary
pressure on the cooker to help here in cleaning up procedure (it surely
helped with us!).

Probably a quarterly regime would work fine. Announce a gamma release
one month before the end of the cycle (and fork there so development
continues), and make abundantly sure that whatever happens, it is going
to be the production version one month later. This shifts quite a bit of
the responsibility for testing back to where it belongs: the users
a.k.a. the Squeak community.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030228/3dbadc0e/attachment.pgp
Daniel Vainsencher
2012-01-28 11:21:06 UTC
Permalink
I mean that we'll need a better mechanism than this for updating
packages that are in the image. Putting them in the package will cause
problems when, for example, a different change gets applied in the
update stream.

But I agree it's a good short term solution.

Daniel

Ned Konz <***@bike-nomad.com> wrote:
> On Thursday 27 February 2003 05:30 pm, Daniel Vainsencher wrote:
> > 2. Archive viewer bug fix gets auto-installed by SARInstaller
> > (which, btw, has it's own problems).
>
> Is there something I missed there?
>
> --
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
Hannes Hirzel
2012-01-28 11:21:06 UTC
Permalink
Hi Craig

Craig Latta <***@netjam.org> wrote:
>
> 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.


An example of an emerging test culture

>"Brent Vukmer" <***@blackboard.com> wrote:
> I installed the MetaClassBuilderFix SAR in a 3.4gamma image,
> installed the ClassBuilder test suite,
> and then ran the ClassBuilder test suite
> -- 3 out of 3 tests passed.
>

Cheers

Hannes
Jimmie Houchin
2012-01-28 11:21:07 UTC
Permalink
From my memory, it seems that the most recent goal of a 3.4 release was
to finalize Squeak as a release which primarily occurred under the
stewardship of Squeak Central.

Squeak 3.5x and forward were to be the releases under the Guide system.
It can be somewhat confusing since it appears that a "Guide" is
releasing 3.4. However, the purpose did not change.

While Squeak is not currently under any commercial or business type time
pressure, there are people who do base certain events on releases. For
example Stephane Ducasse sometimes releases materials (writings) which
are based on a certain Squeak release. Some people burn cds for
education and other distributions. So having a certain release which is
frozen does advantage these people. Sometimes do to their release
schedules some time pressure can be asserted.

I hope this makes sense.

Jimmie Houchin
Doug Way
2012-01-28 11:21:08 UTC
Permalink
Jimmie Houchin wrote:
>
> From my memory, it seems that the most recent goal of a 3.4 release was
> to finalize Squeak as a release which primarily occurred under the
> stewardship of Squeak Central.
>
> Squeak 3.5x and forward were to be the releases under the Guide system.
> It can be somewhat confusing since it appears that a "Guide" is
> releasing 3.4. However, the purpose did not change.

Yes, it did sort of work out that way. Scott Wallace from SqC actually
handled the bulk of the update-stream additions during 3.4, and he and I
worked together on transitioning the update stream duties over to me. We
worked through some glitches in the process, but once I had it all working, it
seemed to make more sense for me to handle the final steps of the 3.4 release.

> While Squeak is not currently under any commercial or business type time
> pressure, there are people who do base certain events on releases. For
> example Stephane Ducasse sometimes releases materials (writings) which
> are based on a certain Squeak release. Some people burn cds for
> education and other distributions. So having a certain release which is
> frozen does advantage these people. Sometimes do to their release
> schedules some time pressure can be asserted.

Good points here.

- Doug Way
Craig Latta
2012-01-28 11:21:07 UTC
Permalink
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.
>
> An example of an emerging test culture
>
> > "Brent Vukmer" <***@blackboard.com> wrote:
> > I installed the MetaClassBuilderFix SAR in a 3.4gamma image,
> > installed the ClassBuilder test suite,
> > and then ran the ClassBuilder test suite
> > -- 3 out of 3 tests passed.

Indeed, but to what extent should particular tests delay a particular
release? I think that's the main issue here.


thanks,

-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
Hannes Hirzel
2012-01-28 11:21:07 UTC
Permalink
Hello Craig


Craig Latta <***@netjam.org> wrote:
>
> 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.
> >
> > An example of an emerging test culture
> >
> > > "Brent Vukmer" <***@blackboard.com> wrote:
> > > I installed the MetaClassBuilderFix SAR in a 3.4gamma image,
> > > installed the ClassBuilder test suite,
> > > and then ran the ClassBuilder test suite
> > > -- 3 out of 3 tests passed.
>
> Indeed,

Great! You got the message about tests ;-)

Let's move on to the next topic

>but to what extent should particular tests delay a particular
> release? I think that's the main issue here.
>
>
> thanks,
>
> -C
>

Excellent question!

IMHO the main issue is that if I look at
http://swiki.squeakfoundation.org/squeakfoundation/70

I see the names of the guides:
* Doug Way
* Daniel Vainsencher
* Ned Konz
* Craig Latta
* Göran Hultgren
* Tim Rowledge

Then I click on the link 'Release Plan'
(http://swiki.squeakfoundation.org/squeakfoundation/79)

Then I read

3.4 -- The main purpose of this release is to create an

up to date,
viable version,
that's a good starting point
to making Squeak more modular and it's development more
decentralized.

Changes:

- Includes non-modules related updates from 3.3a, including the dynamic
filelist services refactoring.

- An option to load the SqueakMap package catalog and the base Package
Loader from the net.

- A dynamic open menu so packages can now register there and become
first class applications.

- Refactorings making various parts of the image easily removable. See
Modularizing the Squeak image for the plan and status.

- Various other fixes have been included.

Release is tentatively set to end of 2002.

------
Now a question everybody who is looking at your work would come up with:

Are these goals met and if yes by which criteria is this evaluated.
You have put five points on this list. What do you have to say about
them
at the end of February?

Postponing an issue is fully a viable option if there are important new
reasons coming up.
This has to be discussed and communicated.

And: A list of open issues and major known bugs is surely a useful tool
for guiding a development process.

I do not see any links on the above mentioned pages.

In the SqC area for various reasons Dan Ingalls used to be the
"development process"
(chief programmer approach). Because of his long experience he just took
care of a lot of things.
In the post SqC area the process should be made more explicit. We have
all these nice tools and communication aids (mailing lists, Swikis /
even world wide phone calls are accessible for many) - why not use them?

I'm hoping that this stimulates you to not soley focus on schedule
issues. I really recommend you to (re)read the excellent write-up by
Daniel Vainsencher about the nature of releases
http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from
today).

Regards and happy Squeaking!

Hannes



P.S. My emphasis for having a proper (not perfect!) 3.4 release is
motivated by my fears it might be the base for further development for a
rather long time. This is fed by the fact that on the release plan
(http://swiki.squeakfoundation.org/squeakfoundation/79) there is no
single sentence about 3.5 not to speak of 3.6 and 3.7.
Craig Latta
2012-01-28 11:21:07 UTC
Permalink
> Great! You got the message about tests ;-)

I've known the importance of tests for quite some time.


-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
goran.hultgren at bluefish.se ()
2012-01-28 11:21:13 UTC
Permalink
Hi all!

Ok, this post is a bit "annoyed" (typing this line in afterwards). Hey,
it happens in even the best of families. ;-)

Hannes Hirzel <***@bluewin.ch> wrote:
[SNIP]
> >but to what extent should particular tests delay a particular
> > release? I think that's the main issue here.
> >
> >
> > thanks,
> >
> > -C
> >
>
> Excellent question!
>
> IMHO the main issue is that if I look at
> http://swiki.squeakfoundation.org/squeakfoundation/70
>
> I see the names of the guides:
> * Doug Way
> * Daniel Vainsencher
> * Ned Konz
> * Craig Latta
> * Göran Hultgren
> * Tim Rowledge
>
> Then I click on the link 'Release Plan'
> (http://swiki.squeakfoundation.org/squeakfoundation/79)
>
> Then I read
>
> 3.4 -- The main purpose of this release is to create an
>
> up to date,
> viable version,
> that's a good starting point
> to making Squeak more modular and it's development more
> decentralized.
>
> Changes:
>
> - Includes non-modules related updates from 3.3a, including the dynamic
> filelist services refactoring.
>
> - An option to load the SqueakMap package catalog and the base Package
> Loader from the net.
>
> - A dynamic open menu so packages can now register there and become
> first class applications.
>
> - Refactorings making various parts of the image easily removable. See
> Modularizing the Squeak image for the plan and status.
>
> - Various other fixes have been included.
>
> Release is tentatively set to end of 2002.
>
> ------
> Now a question everybody who is looking at your work would come up with:
>
> Are these goals met and if yes by which criteria is this evaluated.
> You have put five points on this list. What do you have to say about
> them
> at the end of February?

Well, I think it looks good. :-) Personally I think we aimed to include
refactorings that "got finished". I wouldn't characterize them as being
the goal though. If that was the case then 3.4 would have taken a
loooong time.

> Postponing an issue is fully a viable option if there are important new
> reasons coming up.
> This has to be discussed and communicated.

And it *is* being discussed all the time.

> And: A list of open issues and major known bugs is surely a useful tool
> for guiding a development process.

Indeed. Would you mind setting one up? I have made offers earlier in
this regard but will keep my focus on SM. (Hint: The guides aren't SqC.
We are not intended to do the work *for* the community.)

It would of course be good if a bugsystem was integrated in Squeak
otherwise it will not be used much I think.

> I do not see any links on the above mentioned pages.

But you did see that it said "sketch" at the top I presume?

> In the SqC area for various reasons Dan Ingalls used to be the
> "development process"
> (chief programmer approach). Because of his long experience he just took
> care of a lot of things.
> In the post SqC area the process should be made more explicit. We have
> all these nice tools and communication aids (mailing lists, Swikis /
> even world wide phone calls are accessible for many) - why not use them?

We *are* using them. (Getting a bit annoyed here, but I will just count
to 10)

(I agree though on making the process more explicit - we are trying
hard)

> I'm hoping that this stimulates you to not soley focus on schedule
> issues.

Guess what? This post doesn't stimulate me to do anything at all.
Perhaps I am in a bad mood today (didn't think I was because 3.4 just
got released but hey) but you are simply just making me annoyed.

I am one of the guides but the whole point with calling us "guides" is
because we are *just* that. The intention is that we are all in this
together and that we are doing it all because it is fun.

And if you are asking for directions for future releases (3.5 and
beyond) - hell, I have a couple of good ideas about 3.5 but that is it.
We don't know more than you do and we don't communicate outside of the
SqF-list so WYSIWYG.

If you want to hear my ideas about 3.5 then just *ask* me/us.

> I really recommend you to (re)read the excellent write-up by
> Daniel Vainsencher about the nature of releases
> http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from
> today).

I have read it, I read everything Daniel writes. It is good as always.

> Regards and happy Squeaking!
>
> Hannes

regards, Göran
Daniel Vainsencher
2012-01-28 11:21:07 UTC
Permalink
Hi Hannes.

Let's see if we can summarize and answer your points -

[Tests]
Tests are needed, us Guides know this, you're preaching to the choir.
The community should continue to supply tests, and some will be used to
approve releases. We won't use tests we don't have. If someone compiles,
as has been suggested, a test package on SM, it might help.

[Status - everyone should know where each release stands. Could be
solved with a bug/issue DB]
You're right. We need such a tool, but - we need more urgently a fix
tracking tool, to make sure we don't lose work that people submit -
fixes are higher priority than bugs, because people become more upset
when you lose their changesets than when you ignore their bugs.

We're planning to make such a tool, but we haven't made much progress in
that, either. We could really use some help from the community with
either of them.

About reporting status - Actually, in the Linux community, there's a guy
that simply follows the discussions, Linus and gets updates from other
developers, and maintains a list of patches/issues, and where in the
pipeline they are (planning coding testing in - sort of like the list I
made for refactorings). He updates this list and posts it publically
every so often. This could be done once a month. As you say, it would
help everyone immensely, by keeping us all on the same page and showing
us exactly what's stuck. If anyone from the documentation project or at
all is volunteering to provude such a status report on a regular basis,
that'd bee a meaningful contribution to the community.

[You want a near perfect release for 3.4]
Your objections have been noted, the bugs have been rated as
non-critical, and a release will be issued at Doug's convinience. Fixes
for the bugs that have been proposed will be reviewed and passed into
3.5a quite soon after the release of 3.4.

[You fear that 3.4 will last a long time because there's no explicit
plan for 3.5]
One will be made, after 3.4 is laid to rest, with the participation of
the community, as you've been told by both Craig and I before. Your
fears are probably unfounded - we have spoken about 3.5 as a probably
second short release to get the process optimized. You're welcome to
find this on the squeakfoundation archives, where all discussions on
this topic reside.

[focus]
We don't at all focus solely on schedule issues, to say this is to
ignore the distinguishable amounts of verbiage us Guides have been
generating, some of us more than others, on completely other topics
<embarrassed grin>. But actually, our sole page of real hard policy,
which is linked off the release plan page, is "the lifecycle of a
release" page, which you should read, because it's concerned with
quality, and it is that that we're attempting to follow.

Daniel


Hannes Hirzel <***@bluewin.ch> wrote:
> Now a question everybody who is looking at your work would come up with:
>
> Are these goals met and if yes by which criteria is this evaluated.
> You have put five points on this list. What do you have to say about
> them
> at the end of February?

> Postponing an issue is fully a viable option if there are important new
> reasons coming up.
> This has to be discussed and communicated.
>
> And: A list of open issues and major known bugs is surely a useful tool
> for guiding a development process.
>
> I do not see any links on the above mentioned pages.
>
> In the SqC area for various reasons Dan Ingalls used to be the
> "development process"
> (chief programmer approach). Because of his long experience he just took
> care of a lot of things.
> In the post SqC area the process should be made more explicit. We have
> all these nice tools and communication aids (mailing lists, Swikis /
> even world wide phone calls are accessible for many) - why not use them?
>
> I'm hoping that this stimulates you to not soley focus on schedule
> issues. I really recommend you to (re)read the excellent write-up by
> Daniel Vainsencher about the nature of releases
> http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from
> today).
>
> Regards and happy Squeaking!
>
> Hannes
>
>
>
> P.S. My emphasis for having a proper (not perfect!) 3.4 release is
> motivated by my fears it might be the base for further development for a
> rather long time. This is fed by the fact that on the release plan
> (http://swiki.squeakfoundation.org/squeakfoundation/79) there is no
> single sentence about 3.5 not to speak of 3.6 and 3.7.
Doug Way
2012-01-28 11:21:08 UTC
Permalink
Daniel Vainsencher wrote:
>
> ...
> [Status - everyone should know where each release stands. Could be
> solved with a bug/issue DB]
> You're right. We need such a tool, but - we need more urgently a fix
> tracking tool, to make sure we don't lose work that people submit -
> fixes are higher priority than bugs, because people become more upset
> when you lose their changesets than when you ignore their bugs.
>
> We're planning to make such a tool, but we haven't made much progress in
> that, either. We could really use some help from the community with
> either of them.

I put together a swiki page awhile ago (which I just updated a bit) with some
initial thoughts on how such a tool might work:

http://swiki.squeakfoundation.org/squeakfoundation/86

Feel free to add comments at the end of the page. I'm planning to start
working on this as soon as 3.4 is released, but if anyone else is interested
in helping out with this, that would be great.

- Doug Way
Daniel Vainsencher
2012-01-28 11:21:08 UTC
Permalink
Makes perfect sense to me.

Daniel

Jimmie Houchin <***@texoma.net> wrote:
> From my memory, it seems that the most recent goal of a 3.4 release was
> to finalize Squeak as a release which primarily occurred under the
> stewardship of Squeak Central.
>
> Squeak 3.5x and forward were to be the releases under the Guide system.
> It can be somewhat confusing since it appears that a "Guide" is
> releasing 3.4. However, the purpose did not change.
>
> While Squeak is not currently under any commercial or business type time
> pressure, there are people who do base certain events on releases. For
> example Stephane Ducasse sometimes releases materials (writings) which
> are based on a certain Squeak release. Some people burn cds for
> education and other distributions. So having a certain release which is
> frozen does advantage these people. Sometimes do to their release
> schedules some time pressure can be asserted.
>
> I hope this makes sense.
>
> Jimmie Houchin
Richard A. O'Keefe
2012-01-28 11:21:12 UTC
Permalink
Daniel Vainsencher <***@netvision.net.il> wrote:
> It's about having many releases, at quite frequent, predictable
> intervals, that are getting better and better, and keeping
> production and development close.
and Simon Michael <***@joyful.com> wrote:
I've found releasing on the first of every month to be a useful
discipline.

They've helped me understand why I've been bothered about the Squeak
release process.

Basically, the current idea seems to be that Squeak users should
1. Download some release of Squeak.
2. Periodically use the "Squeak" flap to download and install patches.

There ARE many releases. Every time the "current patches" set is increased,
that's in effect a new release. These releases are fairly frequent, albeit
not at predictable intervals. They do make the system better and better.

So if you are happy to keep all your work in change sets (or SARs or
whatever) then you can from time to time start up a fresh image, download
and install the latest patches, save your image as new fresh image,
and reload your work.

Let's face it, this is a lot easier than keeping almost any other package
up to date. If I want the latest version of some Scheme system, I have to
download patches, apply them, and rebuild the whole thing. I really only
*have* to download a whole new Squeak system when the VM changes, and VM
changes are rarer than other kinds of changes.

So we HAVE a process for frequent releases and it is USED.

Why don't I like it? I could give you a list of reasons, but I suspect
that the defect is really in me. Perhaps I'm still not used to doing
things the Squeaky way.
Stephane Ducasse
2012-01-28 11:21:13 UTC
Permalink
I agree.

On Monday, March 3, 2003, at 09:41 AM, ***@bluefish.se wrote:

> Sidenote: Making automated "releases" like the first every month is
> IMHO
> not a "release". That is more like a nightly build. The release isn't a
> release just because we say it is - it is a release because we have
> been
> going through the alpha/beta/gamma phases. Doing that in one month
> doesn't sound useful to me.
>
> But I agree that we can try to make some form of regular schedule for
> the releases. 2 per year sounds reasonable to me (just a hipshot).

Having two release a year sounds reasonable and will push the CD
production :).

Stef


Prof. Dr. St?phane DUCASSE (***@iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes
Hannes Hirzel
2012-01-28 11:21:13 UTC
Permalink
Hi Goran and all

***@bluefish.se wrote:
> > And: A list of open issues and major known bugs is surely a useful tool
> > for guiding a development process.
>
> Indeed. Would you mind setting one up? I have made offers earlier in
> this regard but will keep my focus on SM. (Hint: The guides aren't SqC.
> We are not intended to do the work *for* the community.)
>

I'm interested in looking at your offers. It would help me if you
could post the links to them.
A quick look (10 min) at the titles your last 300 posts of this list
does not show anything like that.
(including http://lists.squeakfoundation.org/listinfo/squeakfoundation)

And the list on http://swiki.squeakfoundation.org/squeakfoundation/88
is not terribly maintained. Last change 19-DEC-02.

How do you think volunteers can notice possible tasks they could
help if they don't preceive them? We are not computers.
Just writing something in the body of an email somewhere
does not get noticed.

BTW The high number of your post shows an incredible
energy and enthusiasm. Thanks a lot! But wouldn't it be an idea
for every 20th email you write to update *one* swiki
page on www.squeakfoundation.org and point people to them
from time to time (e.g. once every month)?

So much energy / knowhow and person-hours are
available for bringing Squeak foward, but for reasons I'm not yet fully
aware of a lot of this energy dissipates unused because of poor
follow ups.

-- Hannes


P.S. Perhaps somebody could write an opportunity statement
regarding this. I'll try to make up my mind of this as well.
goran.hultgren at bluefish.se ()
2012-01-28 11:21:14 UTC
Permalink
Hi Hannes and all!

Hannes Hirzel <***@bluewin.ch> wrote:
> Hi Goran and all
>
> ***@bluefish.se wrote:
> > > And: A list of open issues and major known bugs is surely a useful tool
> > > for guiding a development process.
> >
> > Indeed. Would you mind setting one up? I have made offers earlier in
> > this regard but will keep my focus on SM. (Hint: The guides aren't SqC.
> > We are not intended to do the work *for* the community.)
>
> I'm interested in looking at your offers. It would help me if you
> could post the links to them.
>
> A quick look (10 min) at the titles your last 300 posts of this list
> does not show anything like that.
> (including http://lists.squeakfoundation.org/listinfo/squeakfoundation)

Well, that is because it was back in october/november 2001. About 2000
emails ago. Christ. :-)

> And the list on http://swiki.squeakfoundation.org/squeakfoundation/88
> is not terribly maintained. Last change 19-DEC-02.

I am not sure what that list has got to do with this? That is a list of
roles that people have taken on.
Not a wishlist for people to sign up on.

> How do you think volunteers can notice possible tasks they could
> help if they don't preceive them? We are not computers.

No, we are humans. Humans communicate. Exactly what are you "accusing"
me of here?
Not telling volunteers what they can do? Not writing down a list
somewhere what they can do?

There are tons of places on both the Squeak Swiki and also the SqF swiki
where there are needs listed.

And needs are almost daily communicated on these two mailing lists. The
need for good bug tracking is not new, we have had it for years.

> Just writing something in the body of an email somewhere
> does not get noticed.

Duh.

> BTW The high number of your post shows an incredible
> energy and enthusiasm.

Yes.

> Thanks a lot! But wouldn't it be an idea
> for every 20th email you write to update *one* swiki
> page on www.squeakfoundation.org and point people to them
> from time to time (e.g. once every month)?

Well, personally I am not too fond of Swikis exploding into a jungle of
old pages.
Secondly I don't want the SqF swiki to compete with the Squeak Swiki so
it should be kept small and to the point.
Thirdly... I am at a loss of words. You are actually telling me to
update a Swiki page every 20 email?!?

> So much energy / knowhow and person-hours are
> available for bringing Squeak foward, but for reasons I'm not yet fully
> aware of a lot of this energy dissipates unused because of poor
> follow ups.

There are tons of reasons. Not having everybody spewing out Swiki pages
is IMHO not one of them.
Not having a bug tracking system is one though, an important one.
Discussing in which posting I offered to set one up is not one of them
either.

Btw, Jitterbug is a simple webbased system that could possibly work but
even though it does sound like he NIH-syndrome I actually think we could
do better by building something integrated in Squeak - like SM. SM just
didn't lift off until it was accessible from inside Squeak.

regards, Göran
goran.hultgren at bluefish.se ()
2012-01-28 11:21:14 UTC
Permalink
***@bluefish.se wrote:
[SNIP]
> Btw, Jitterbug is a simple webbased system that could possibly work but
> even though it does sound like he NIH-syndrome I actually think we could
> do better by building something integrated in Squeak - like SM. SM just
> didn't lift off until it was accessible from inside Squeak.

What I mean with this is that I think (now 2 years later) an external
webbased bug tracking system - no matter how simple (Jittebug is very
simple for example) - would not turn out good. I think it would be
better if we "cooked our own". Btw, Julian Fitzell probably has good
ideas in this area too - I believe he told me that he had worked on one
of the OSS tools in this area. (Personally I have installed/hacked and
made Jitterbug work in a 12 developer company - but the needs where
probably different from Squeak.)

Yes, it sounds really NIH-ish and not STTCPW either, but I think the
importance of integration in the tools/image plus integration with SM
and/or the new Harvesting tool is of extreme importance.

And in fact - the bug tracking system may very well *be* the new
Harvesting tool, what do I know.

I just know that we need support for bug tracking and harvesting and
both mechanisms should IMHO be package aware and integrated in the
Squeak environment.


regards, Göran
Doug Way
2012-01-28 11:21:16 UTC
Permalink
Finally catching up on some list email...

On Monday, March 3, 2003, at 09:22 AM, ***@bluefish.se wrote:

> Hi Hannes and all!
>
> Hannes Hirzel <***@bluewin.ch> wrote:
>
> ...
>> And the list on http://swiki.squeakfoundation.org/squeakfoundation/88
>> is not terribly maintained. Last change 19-DEC-02.
>
> I am not sure what that list has got to do with this? That is a list of
> roles that people have taken on.
> Not a wishlist for people to sign up on.

To make things a bit clearer, I just added some text this page saying:
"If you have a strong interest in volunteering for a role (that is not
already listed here or under Guide roles), please post to the
Foundation Mailing List first to make your interest known."

I think that's a reasonable way to handle things. After discussion it
can be determined whether the proposed role makes sense, whether
someone else is already doing it, etc.

>> So much energy / knowhow and person-hours are
>> available for bringing Squeak foward, but for reasons I'm not yet
>> fully
>> aware of a lot of this energy dissipates unused because of poor
>> follow ups.
>
> There are tons of reasons. Not having everybody spewing out Swiki pages
> is IMHO not one of them.
> Not having a bug tracking system is one though, an important one.
> Discussing in which posting I offered to set one up is not one of them
> either.
>
> Btw, Jitterbug is a simple webbased system that could possibly work but
> even though it does sound like he NIH-syndrome I actually think we
> could
> do better by building something integrated in Squeak - like SM. SM just
> didn't lift off until it was accessible from inside Squeak.

Absolutely. For a lot of things it doesn't make much sense to
"reinvent the wheel", but with something like SqueakMap or a bug/bugfix
tracking/harvesting system, the benefits for integrating closely with
Squeak are too great too ignore. Plus a bug tracking system is not a
particularly difficult wheel to reinvent. :-)

- Doug Way
Doug Way
2012-01-28 11:21:16 UTC
Permalink
On Friday, February 28, 2003, at 11:56 AM, Simon Michael wrote:

> ...
> I've found releasing on the first of every month to be a useful
> discipline.
> What changes would be needed to make this practical for squeak, I
> wonder ?
> Maybe none.

I think releasing every month probably isn't realistic, and I'm not
sure it's a good idea anyway.

One problem is that I don't think we'd be able to do it very soon and
still keep a reasonable level of quality in the releases. To attain a
release cycle that rapid, with such short beta/gamma stages, we'd
probably need to have unit tests for the whole image to ensure that
stuff wasn't breaking. We're not too close to that point yet. (I
agree there are some advantages to a rapid release cycle, though.)

Another problem is that I'm not sure a monthly release with new
features in every release is desirable for a public "stable" software
release, even if they are relatively bug-free.

For example, let's say Squeak 3.5 is released in April, 3.6 in May, 3.7
in June, 3.8 in July, etc., through 4.3 in December. This would
require that people who try to write production-quality packages for
Squeak would constantly have to test their packages to make sure they
work with the latest version.

Or, the owner of package X may not bother and just test it with 3.7 and
declare it compatible with that. Package Y may also be written during
the summertime but its maintainer may have used 3.9 instead. Then, if
some user wants to use package X and package Y together, they wouldn't
be able to. (Or, they would have to at least do some testing to see if
package X still worked in 3.9, which is some effort/worry to deal with.)

Some of these problems might be lessened by having the image split up
into packages with a powerful dependencies scheme in place. (with
compatibility ranges and that sort of thing)

But it still seems that you'd just have too many versions out there for
people to make sense of. :-) Are there any open-source projects out
there which come out with a (non-alpha/non-testing) release as often as
every month? To me, a monthly release makes a lot of sense for
something that is still in development, or perhaps for a level of user
somewhere in between bleeding-edge-alpha tester and stable-product-only
user. I believe Debian has something like that.

Whether a one-time one-month release is appropriate for 3.5 is a
different question, for a different email. :-)

- Doug Way
Continue reading on narkive:
Loading...