RE: WeakArray bug (was Re: [UPDATES] 3.5gamma)

Andreas Raab <[email protected]> wrote:
> > We need more explicit reviews.
> Or more explicit goals ;-) 
Sure. My experience is that the goals one thought up initially are
usually no longer precise enough by the time you're done, so maybe the
thinking cap trigger should be the review. 

Basically, with our current process, that means that the harvesters
should use [approved] with care.

Daniel

> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]] 
> > On Behalf Of Daniel Vainsencher
> > Sent: Saturday, April 05, 2003 3:14 AM
> > To: Discussing the Squeak Foundation
> > Subject: [Squeakfoundation]WeakArray bug (was Re: [UPDATES] 3.5gamma)
> > 
> > 
> > About the 3.5/3.6 decision, sounds reasonable to me. 
> > 
> > About why we got to the state where one of us says a bug 
> > critical enough
> > to stop the release from going out, when we're in gamma - I think we
> > included the fix with the implicit goal of "fixing the class builder"
> > but with the explicit SUnit test of "classes with instance 
> > variables and
> > subclasses can be reshaped properly". 
> > 
> > Nobody said "this fix does X, which is enough. It doesn't do Y, but we
> > can live with that", where Y would be "allow the whole 
> > hierarchy to get
> > rebuilt", for example.
> > 
> > We need more explicit reviews.
> > 
> > Daniel
> > 
> > Doug Way <[email protected]> wrote:
> > > 
> > > Daniel Vainsencher wrote:
> > > > 
> > > > <shifting to sqf list>
> > > > 
> > > > That's an interesting point. Does that mean we actually 
> > delay 3.5, when
> > > > the 3.6 update stream has already started? another 
> > question is, how did
> > > > we get into gamma, when apparently, one of our two goals 
> > for the release
> > > > isn't actually achieved?
> > > 
> > > Tim did mention this as a bug on March 14.  There wasn't 
> > any mention of
> > > whether it was a serious enough problem to try to fix in 
> > 3.5, so I ignored it
> > > for the moment, hoping that someone would come up with a fix.
> > > 
> > > It did appear to be possibly related to the ClassBuilder 
> > problem, but that
> > > wasn't certain, either.  The problem occured with or 
> > without the ClassBuilder
> > > fix.
> > > 
> > > Just now I did a quick check of when the bug was 
> > introduced.  I was guessing
> > > that maybe Andreas introduced it with the ClassBuilder 
> > refactoring/cleanup in
> > > 3.4alpha, which was when the other ClassBuilder bug was 
> > introduced.  However,
> > > that was not the case... I tested 3.2 and the bug is there, 
> > too.  Turns out
> > > this bug is as old as the hills... the bug exists back in 
> > 2.6!  It does not
> > > exist in 2.4, though.  (It's always nice to have old images 
> > lying around. :-) 
> > > I didn't have a 2.5 image handy, though.)
> > > 
> > > So, given that the bug is 3+ years old, and we don't yet 
> > have a fix that we
> > > agree on, I think it's pretty safe to say that we don't 
> > need to address this
> > > in 3.5.  As soon as someone comes up with a good fix, we 
> > can include it in
> > > 3.6alpha.  (Maybe Brent's fix is sufficient, I don't know, 
> > but it hasn't
> > > gotten any feedback yet.)
> > > 
> > > - Doug Way
> > > 
> > > 
> > > > Daniel
> > > > 
> > > > Tim Rowledge <[email protected]> wrote:
> > > > > Daniel Vainsencher <[email protected]> wrote:
> > > > >
> > > > > > AFAICT, this fix is KCP territory. Unless there is a 
> > very good reason
> > > > > > otherwise, I would await their recommendation (and 
> > not delay the
> > > > > > release).
> > > > > Well since the 3.5 release was purported to be mostly 
> > to include a fix
> > > > > for a very similar bug and the bug in question has 
> > pretty similar
> > > > > effects - cannot recompile a number of classes - I'd 
> > say that without a
> > > > > fix we really shouldn't even consider 3.5 in beta in 
> > any meaningful
> > > > > sense.
> > > > >
> > > > > tim
> > > > > --
> > > > > Tim Rowledge, [email protected], 
> > http://sumeru.stanford.edu/tim
> > > > > Spellchecker not found.  
> > Press -- to continue ...
> > > > _______________________________________________
> > > > Squeakfoundation mailing list
> > > > [email protected]
> > > > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > > _______________________________________________
> > > Squeakfoundation mailing list
> > > [email protected]
> > > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > _______________________________________________
> > Squeakfoundation mailing list
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Apr 05 12:58:21 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 11866 invoked from network); 5 Apr 2003 12:58:20 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 5 Apr 2003 12:58:20 -0000
Received: from aSqueakSystem ([80.178.108.27]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sat,
 05 Apr 2003 16:00:33 +0300 (IDT)
Date: Sat, 05 Apr 2003 15:21:39 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]How to proceed for the kernel cleaning
	harvesting
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Celeste 2.0.5174
Content-type: TEXT/PLAIN
Content-transfer-encoding: 8BIT
cc: Alexandre Bergel <[email protected]>
cc: Roel Wuyts <[email protected]>
cc: Nathanael Scharli <[email protected]>
cc: Noury Bouraqadi <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2003 12:58:21 -0000

Hi Stef.

I see what you mean. You want to specialize the general process for your
particular effort. If you bring your own external reviewer, (and I heard
Noury's talk last ESUG, so I have no doubts he can handle the meta
aspects) that makes things easier, you don't need to motivate other
external reviewers. Because he knows the context, he'll understand what
you're doing with less prompting.

It sounds like the front end of the process will be fine.

However, when you specialize a process, you need to make sure the
invariants are kept... here are the invariants we do need to
intelligently [approve] the changes, so they can get into the update
stream.

1. We might not approve a specific change because we don't agree with
the solution, or because we don't agree there's a problem. So, usually,
we request changes be independent of one another, so we can review and
accept/reject them independently, and evaluating their value by
themselves. If you make some changesets interdependent, we still might
not accept a changeset, and then it's your problem to work around it.
This might still work, because you're working with well defined goals. 
2. If you want to help me make a positive decision, make it clear what
problem you're solving, and what design decisions you're making. I don't
need it to be ten lines per method - do the minimum, but communicate
your decisions clearly. Making the changesets small helps. When you mix
different operations in the same change set, it obfuscates (change set
11 converts Smalltalk -> self environment AND changes Behavior
interface, moving things to a new class).
3. An external reviewer is as valuable as his comments. An anonymous
[er] without the text of the review is meaningless. I want to SEE
Noury's comments. Why? I know perfectly well he's a brilliant
meta-programmer, but other than that, I don't know anything about his
criteria. And if he feels something is so-so, I want him to write it
down, so I can consider it too.

If you keep these invariants, I'll do my best to review your changes
(and approve where appropriate) with reasonable dispatch - I think a
clean kernel would be a wonderful thing. And within those invariants, as
part of a specialized process, which I can agree to, we can change
almost any part of the "ceremony" you want, so you can save energy.

Daniel

Stephane Ducasse <[email protected]> wrote:
> Hi doug and others
> 
> We are starting to make progress on the kernel cleaning. However I 
> would like to avoid to have 200 changesets to be included before 
> putting some of them in the stream.
> 
> What is important is that we are decomposing our changes (with pain 
> instead of doing three changes at once we really do them one by one 
> slowly) into
> small changesets so that people can understand them. We are also 
> building a testSuite
> that we will keep in the future as a kind of specification of what we 
> did. We are four working on that and we have our own internal 
> reviewing. We are also introducing a deprecation schema so that tools 
> build before the cleaning will be notified when they used an old method 
> and that people can query the deprecated method. This way we could 
> build a simple tool to identify deprecated methods and build a database 
> with that information for later migration.
> 
> Now the problem is that cleaning the kernel is somehow special and the 
> order of the changesets may be really important. So change 0001 should 
> be put in before 0004 for example. We are focusing on specific parts 
> and we have some major milestones as explained on the page. 
> http://minnow.cc.gatech.edu/squeak/3083
> 
> We can document what we are doing but if for every method move we have 
> to write 10 lines this will never scale. Normally there is a preamble 
> that explain the change but often we cannot spend time motivate them 
> because this is obvious. So I would like to know if some harvesters are 
> really interested in reviewing what we are doing, we are looking for a 
> meta-aware one. I asked Noury (the best meta programmer I know in 
> france father of metaclassTalk which already cure some part of the VW 
> kernel for his PhD) to be an external reviewer. But he is not an 
> harvester but could become one (Noury?)
> 
> So as soon as our own reviewing process will finish for the first 40 
> changesets we will send them into the stream. But we would like to know 
> how to minimize energy.
> 
> 
> Stef
> 
> 
> 
> 
> Prof. Dr. Stéphane DUCASSE
> 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
> 
> "The best way to predict the future is to invent it..." Alan Kay.
> 
> Open Source Smalltalks: http://www.squeak.org, 
> http://www.gnu.org/software/smalltalk/smalltalk.html
> Free books for Universities at 
> http://www.esug.org/sponsoring/promotionProgram.html
> Free Online Book at 
> http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Apr 05 12:58:22 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 11930 invoked from network); 5 Apr 2003 12:58:21 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 5 Apr 2003 12:58:21 -0000
Received: from aSqueakSystem ([80.178.108.27]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sat,
 05 Apr 2003 16:00:34 +0300 (IDT)
Date: Sat, 05 Apr 2003 15:36:11 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]Re: Sublicensing seems possible
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5174
Content-transfer-encoding: 7BIT
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2003 12:58:22 -0000

Ugh.. adding more political motivations and limitations to the license?
I'd be happy to drop that clause entirely (though it might not be
practical). But why should we strengthen this limitation? 
I'm sure you see that using the license as a weapon puts more legal
pressure on it. Look how much clearer BSD is than GPL.

If someone is a miser, bad karma is punishment enough IMO.

Daniel

Tim Rowledge <[email protected]> wrote:
> 
> On Friday, April 4, 2003, at 04:25  PM, Andreas Raab wrote:
> >> Since they were modifying and extending the system they _had_
> >> to release those changes under the SqueakL just like the rest
> >> of us.
> >
> > Slight correction: Squeak-L is not viral. It does not require you to 
> > release
> > modifications under Squeak-L. All it requires is to make the code 
> > "publicly
> > available".
> 
> That could actually be a problem in some cases. Say developer X 
> releases some system changes as required but insists on the GPL. They 
> have been publically released but are effectively unusable within the 
> main system. And I suppose that in a sense it would 'block' us from 
> implementing the same thing unless one could prove it clean. Ugly. 
> Perhaps we need to assert that 'publically available' is interpreted as 
> 'usable in the main public image'.
> 
> tim
> -- 
> [email protected]
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Apr 05 14:38:09 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 13806 invoked from network); 5 Apr 2003 14:38:09 -0000
Received: from mailhub02-skge0.unibe.ch (HELO mailhub02.unibe.ch)
	(130.92.9.53)
	by mail.theinternetone.net with SMTP; 5 Apr 2003 14:38:09 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailhub02.unibe.ch (Postfix) with ESMTP
	id 13F40765D9; Sat,  5 Apr 2003 16:38:09 +0200 (MEST)
Received: from mailhub02.unibe.ch ([127.0.0.1])
 by localhost (mailhub02 [127.0.0.1:10024]) (amavisd-new) with LMTP
 id 22464-01-24; Sat,  5 Apr 2003 16:38:08 +0200 (MEST)
Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4])
	by mailhub02.unibe.ch (Postfix) with ESMTP
	id 975BF765D3; Sat,  5 Apr 2003 16:38:08 +0200 (MEST)
Received: from iam.unibe.ch (asterix [130.92.64.4])
	by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h35Ec7K16251;
	Sat, 5 Apr 2003 16:38:07 +0200 (MET DST)
Date: Sat, 5 Apr 2003 16:38:07 +0200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
To: [email protected]
From: Stephane Ducasse <[email protected]>
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.551)
X-Virus-checked: by University of Berne
cc: Doug Way <[email protected]>
cc: Alexandre Bergel <[email protected]>
Subject: [Squeakfoundation]None of the KCP people are in the squeakF list
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2003 14:38:09 -0000

Hi

Just to let you know that we do not have access to the SqueakFoundation=20=

answer to my email because none of us in there.

I made the mistake to send it there while I only wanted to reach the=20
harvesters.
So if a good soul could forward us the key reactions this would be cool.

Stef



Prof. Dr. St=E9phane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do=20
different? ...  especially if,
  by doing something different, today might not be your last day on=20
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org,=20
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at=20
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at=20
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html=