Incorporating removals & KCP stuff

(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
From [email protected] Tue May 06 22:25:25 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 26243 invoked from network); 6 May 2003 22:25:25 -0000
Received: from 1.2.0.10.in-addr.arpa (HELO cdegroot.com) (10.0.2.1)
  by mail.theinternetone.net with SMTP; 6 May 2003 22:25:25 -0000
Received: (qmail 11362 invoked from network); 6 May 2003 22:25:24 -0000
Received: from unknown (HELO localhost) (127.0.0.1)
  by localhost with SMTP; 6 May 2003 22:25:24 -0000
Subject: Re: [Squeakfoundation]Convincing a harvester
From: Cees de Groot <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
In-Reply-To: <000301c3133c$0e129450$8ef7fea9@atlantis>
References: <000301c3133c$0e129450$8ef7fea9@atlantis>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-WpReNRDP19tOWDow0x5S"
Organization: 
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 07 May 2003 00:25:24 +0200
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: Tue, 06 May 2003 22:25:26 -0000


--=-WpReNRDP19tOWDow0x5S
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2003-05-05 at 21:25, Andreas Raab wrote:

> There are a couple of other packages where I think it would be really goo=
d
> if they were part of the kernel image but these three I feel mostly stron=
gly
> about.
>=20
My take on this: I don't think these (maybe with the exception of
networking) should necessarily be in the kernel in the long run; but for
the short term I think it is necessary to 'intern' these cleanups if
only in order to make sure that whathever is split off later on as a
package is good, separable, and 'canonical'. They are maybe not packages
that should land in the 100k bootstrap image ;-), but I do think that
the functionality is basic enough to warrant some special treatment in
order to make sure that we're left with canonical copies of networking,
font support, and internationalization - three areas that are present in
the image but need work, and the packages indicated by Andreas provide
(part of) that work.=20

The argument could be (and has been, IIRC) that people who are
interested in this stuff can grab it from SM, but running these packages
through the 'add to image, clean up, split off' loop has two important
effects:
- it 'blesses' the package as 'this is what we think should be the
official XXX package';
- it pushes it out to a greater number of alpha testers than when left
on SM.
Also, SM is not there yet. The coming months will be a balance act of
getting people used to SM and making sure they see important code
irrespective of the functionality of SM. Just solving every problem by
pointing to SM at this point in time seems counterproductive to me. SM
should work because it is good, not because Guides/Harvesters tell the
community to use it. That won't work.



--=-WpReNRDP19tOWDow0x5S
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA+uDZU8wOTf+CYnosRAnseAKCkVxsQwr5qnnfCMY9wMT9vs6AfiACfTYOL
Ai/ui2qWfggCyMDEN9PKzcU=
=eIXJ
-----END PGP SIGNATURE-----

--=-WpReNRDP19tOWDow0x5S--