Re: Incorporating removals & KCP stuff

I say just split the removals. Notify the owners/on squeak-dev, and
remove only the packages that can return. We can do the other removals
either as people fix the packages or next release. Let's just get it
over with, so we can go back to work.

Do that, I'll test vs. KCP, we load KCP, and then resume harvesting the
regular stuff.

Daniel

Doug Way <[email protected]> wrote:
> 
> (moving this to the SqF list since we're doing the final coordination now...)
> 
> Daniel Vainsencher wrote:
> > 
> > Ok, I've gone through the KCP stuff. I know we orginally decided to do
> > the removals first, but I had an urge, and this doesn't touch so many
> > different classes that I'm very worried about clashes. Anyway, it seems
> > as the designated reviewer for this specific project I got back from my
> > vacation before the removals were done, and I don't see much reason not
> > to merge these now, but I don't mind checking the conflicts if this
> > proposal isn't accepted.
> 
> Okay, we need to get moving on the KCP stuff and the removals now, so we can
> move on with the 3.6 plan (including the various enhancements we've been
> discussing).
> 
> Here's what I would suggest:  We incorporate the 10 removals first, all in one
> batch as Goran and I suggested.  This would be very soon, let's say tomorrow. 
> Then, Daniel can check for conflicts between the approved KCP items and the
> removals.  My understanding is that there should be few conflicts.
> 
> Then, the adjusted KCP changes can be incorporated (after having at least the
> preambles posted to the list as a sort of final review).  If changes need to
> be made in a few of the removed packages to account for the KCP changes,
> perhaps Daniel could inform the package owners of the required changes.
> 
> 
> Anyway, I think doing all the removals in one batch is the way to go.  There
> will be two types of problems we'll have to deal with:
> 
> 1. Problems/bugs caused by the removals.  These should be relatively minor and
> easy to fix, I'd think.
> 
> 2. Problems/bugs/conflicts when re-loading any or all of the 10 packages. 
> These problems will probably be more significant, but these problems need to
> be pushed back to the package owners at some point anyway.  We're moving to a
> model where package owners need to maintain their packages against base image
> (prerequisite) changes, so we might as well start this now.  It may well be
> that some packages (such as PWS) are not actively maintained and become
> obsolete because no one really uses them.  If that happens, either a more
> active package maintainer will have to step up, or the package could be
> removed from "Squeak Official" status, which would remove it from the public
> release.
> 
> 
> Before thinking about incorporating the 10 removals, I decided to do some
> testing.  To remove the 10 packages, I gave Goran's removal script a try. 
> That appears to work.
> 
> Then I decided to try re-adding the 10 packages one by one into an image to
> get back to the "Full" release.  I did it in this order, with the following
> results:
> 
> 1. SUnit - Yes.
> 2. BaseImage Tests - Yes.
> 3. Celeste Installation - Yes.
> 4. Games (and GamesTests) - Yes.
> 5. VMMaker - No.  Not auto-installable, but trying to download it results in a
> "MNU: download", even after setting the download directory.
> 6. MacroBenchmarks - No.  Couldn't find a MacroBenchmarks package on SM!
> 7. PWS Installation - Yes.
> 8. Scamper - Yes.
> 9. Speech - No.  Installation results in a "MNU: arpabet".
> 10. Balloon3D - Yes.
> 
> So, we need to at least fix the loading problems with the three packages
> before incorporating the removals.
> 
> Beyond that, ideally we'd also like to have Test packages for all 10 of these
> packages as well, which pass... right now only a few packages have them.  I
> don't think we should hold up incorporating the removals for this, though. 
> But we should probably try to have them available before we move to 3.6beta,
> at least.  Marcus and I can work on bugging the package owners to create these
> Test packages.  All future package removal/additions will have to have a
> corresponding Test package ahead of time so we don't get in this situation
> again.
> 
> We still need to resolve the issue of how I should load the removal script
> without SqueakMap, SAR, etc., because those won't be there in the vanilla
> 3.6alpha image.  Probably SAR is the only really important one... I don't know
> if any require DVS.  I guess I'll just have to poke around with the removal
> scripts and make them into a series of regular file-ins.  (An alternative
> might be to include SAR in the base image for now.  SAR should probably be
> part of the Full and Basic releases anyway.  Yes, we would end up splitting
> off SAR again sometime later as we whittled down to the Minimal image, but so
> what?  Same probably goes for SqueakMap.)
> 
> - Doug Way
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Wed May 07 00:37:25 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 16780 invoked from network); 7 May 2003 00:37:25 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 7 May 2003 00:37:25 -0000
Received: from aSqueakSystem ([80.178.97.79]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTPA id <[email protected]> for
 [email protected]; Wed,
 07 May 2003 03:39:46 +0300 (IDT)
Date: Wed, 07 May 2003 03:11:35 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]Network stuff
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: Wed, 07 May 2003 00:37:26 -0000

If nobody has particular objections, I propose we do that next step
after merging KCP, which should be after the removals. 

Michael, if you can announce the update on squeak-dev, and also get a
few people that have an interest to test it before we get to that point
and report, that would be cool. 

Daniel

Michael Rueger <[email protected]> wrote:
> Daniel Vainsencher wrote:
> 
> 
> > Mike, your current stance on this would be useful...
> 
> Trying to keep up ;-)
> 
> IMHO the network rewrite should go into the update stream soon (meaning: 
> now ;-) ).
> As Craig wrote in another mail it basically replaces the upper layers of 
> the network code and decouples it from the raw network access by always 
> going through SocketStream. This should make it easier to replace the 
> lower levels by e.g. Flow without breaking applications using the 
> protocol clients.
> 
> I just uploaded the latest version for 3.5 (should work in 3.6 too), 
> please check if I broke anything (new).
> 
> 
>  > this effect in 3.6a, giving people time to adjust/find bugs in the core
>  > Socket, if there is any. Then we can use 3.7 to break the interface (by
>  > removing the default actions) and let people adjust the applications.
> 
> I agree with the above :-)
> 
> Regarding http:
> I started the rewrite, then realized that I should merge it with 
> Comanche. Then seaside and later Comanche NG came up and I decided to 
> wait a little to see which architecture would emerge in that context. 
> Now might be a good time to take a look again.
> 
> Cheers
> 
> Michael
> 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Wed May 07 05:43:59 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 8941 invoked from network); 7 May 2003 05:43:59 -0000
Received: from mailhost2-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det3.ameritech.net) (206.141.193.106)
	by mail.theinternetone.net with SMTP; 7 May 2003 05:43:59 -0000
Received: from riskmetrics.com ([66.72.180.255])
	by mailhost.det3.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030507054352.ORSA176.mailhost.det3.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Wed, 7 May 2003 01:43:52 -0400
Date: Wed, 7 May 2003 01:42:09 -0400
Subject: Re: [Squeakfoundation]Incorporating removals & KCP stuff
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Doug Way <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.552)
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: Wed, 07 May 2003 05:43:59 -0000


On Tuesday, May 6, 2003, at 08:19 PM, Daniel Vainsencher wrote:

> I say just split the removals. Notify the owners/on squeak-dev, and
> remove only the packages that can return. We can do the other removals
> either as people fix the packages or next release. Let's just get it
> over with, so we can go back to work.

That sounds like a plan... I will just incorporate the 7 removal 
packages that had add-on packages that could be loaded properly, and we 
can do the others as they get fixed.

Looking more carefully, it looks like the "Benchmarks" package includes 
the MacroBenchmarks package that I thought was missing.  So that one's 
probably okay.

- Doug


> Do that, I'll test vs. KCP, we load KCP, and then resume harvesting the
> regular stuff.
>
> Daniel