Re: 3.6 MasterPlanner!?

I haven't timeto offer much to planning right now since I'm trying to
get the VMMaker package (re)done and working on tools to build images to
spec and handling Canada paperwork and on and on. 
In an effort to be helpful, here are comments on current suggestions:-

> * Apply some number of package removals to the image.  (Perhaps you were
> taking this one for granted.)  I don't think we should try to plan exactly
> which ones will be removed, but we could set a rough goal of a certain number
> of MB removed from the image, perhaps.
Before any goals relating to size, number or whatever we should
establish a _quality_ goal. For example, no removal package is much use
unless the package can subsequently be installed and actually work. This
relates to the problem I'm having right now with filing out a changeset
not being even close to filing out the classes individually. Without
tools that let package maintainers work sensibly we're going to be in
trouble pretty quick.

> * Remove the Apple fonts from the image, and replace them with functionally
> similar bitmap fonts.  We would still need to decide whether this meant the
> Accufonts, or a move to ISO-8859-1.
Simplest first I'd say. Just get the Apple fonts out and _something_ in.
Accufonts seem reasonable to me. One could consider use of TTFs since
there are quite a lot of reasonable TTF free fonts around. That would
involve some decision on $_ etc. :-(

> > * Restart harvesting using the new process, hopefully removing some
> > backlog.
Some explicable process and cleaning up of swiki pages would help here.
I tried a week or two ago and got lost in a forest of oldlinks and
irelevant pages. And at the end I still didn't understand where to send
code I wanted reviewed or to approve.
> > * Get the simulator fixes by Craig back in.
Yes. THe various fixes he & Anthony worked out get an image running ok.
I think a bunch of simulatorclasses for plugins are still needed really.

> > * Start merging Anthony's work. Run time stuff is a good place to start.
The extra prims are harmless and easy and would allow people to load a
normal package effectively. As for the rest, well I still don't really
know. Ian needs to be involved but it can be tricky to keep his
attention.

> > * Start merging MCP's work, as they start to send it to us. Same for
> > KCP, except I for one am less aware of what they're working on, and have
> > less of an idea as to whether they'll have something ready to merge
> > anytime soon.
Yes. Let's encourage decent discussion on these as well.

> > * Networking/Streams/Sockets is something where a few people have put in
> > quite a lot of work. Find a way to start merging at least some of this
> > stuff, in small pieces. Ideally, we should do everything possible
> > without breaking networking applications. Then break networking (start
> > raising exceptions instead of dialogs) in 3.7alpha.
Flow? Filename cleanups? There's a boatload of crap to bail out of the
boat.
> > * SM 1.1

tim
-- 
Tim Rowledge, [email protected], http://sumeru.stanford.edu/tim
Useful random insult:- Monorail doesn't go all the way to Tomorrowland.
From [email protected] Sun Apr 06 04:14:56 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 29088 invoked from network); 6 Apr 2003 04:14:56 -0000
Received: from mailhost1-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det2.ameritech.net) (206.141.193.105)
	by mail.theinternetone.net with SMTP; 6 Apr 2003 04:14:56 -0000
Received: from riskmetrics.com ([66.72.184.202])
	by mailhost.det2.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030406041454.XZOX8853.mailhost.det2.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Sat, 5 Apr 2003 23:14:54 -0500
Date: Sat, 5 Apr 2003 23:14:55 -0500
Subject: Re: [Squeakfoundation]3.6 MasterPlanner!?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
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.551)
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: Sun, 06 Apr 2003 04:14:56 -0000


On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:

>> * Apply some number of package removals to the image.  (Perhaps you 
>> were
>> taking this one for granted.)  I don't think we should try to plan 
>> exactly
>> which ones will be removed, but we could set a rough goal of a 
>> certain number
>> of MB removed from the image, perhaps.
> Before any goals relating to size, number or whatever we should
> establish a _quality_ goal. For example, no removal package is much use
> unless the package can subsequently be installed and actually work. 
> This
> relates to the problem I'm having right now with filing out a changeset
> not being even close to filing out the classes individually. Without
> tools that let package maintainers work sensibly we're going to be in
> trouble pretty quick.

Yes, quality of package removals/additions should be more important 
than making sure we reach a specific target number/size of removals.  
The size goal for removals could be more of a prediction than a 
must-have goal.

As far as quality criteria for package removals go, we'd have the usual 
harvesting criteria as a minimum (externally tested, etc.), which 
should hopefully cover things like the package addition being 
installable and generally working.

One other quality criteria for package removals/additions that I was 
wondering about:  Should we have a strict rule that package removals 
can only remove classes and (class-extension) methods, they cannot 
overwrite any methods?  Conversely, package additions could only add 
classes and (class-extension) methods, no method overwrites.  This 
would of course often require that some refactoring be done in 
preparation for the removal, so that registering menus were used, etc.  
(And we already have a plan that refactorings should be done prior to 
removal, anyway.)  However, having this as a general rule might be 
unrealistically strict. (?)

>> * Remove the Apple fonts from the image, and replace them with 
>> functionally
>> similar bitmap fonts.  We would still need to decide whether this 
>> meant the
>> Accufonts, or a move to ISO-8859-1.
> Simplest first I'd say. Just get the Apple fonts out and _something_ 
> in.
> Accufonts seem reasonable to me. One could consider use of TTFs since
> there are quite a lot of reasonable TTF free fonts around. That would
> involve some decision on $_ etc. :-(

I agree that Accufonts seem reasonable.  We'd have to agree that the 
license was acceptable and Squeak compatible (which I think it is, 
IMO).  Even after adding the Accufonts, we could have a move toward 
supporting ISO-8859-1, as soon as someone did the required work.

>>> * Restart harvesting using the new process, hopefully removing some
>>> backlog.
> Some explicable process and cleaning up of swiki pages would help here.
> I tried a week or two ago and got lost in a forest of oldlinks and
> irelevant pages. And at the end I still didn't understand where to send
> code I wanted reviewed or to approve.
> ...

Yes, I've been meaning to clean these pages up and have a good summary 
of the process... I will try to get to this ASAP.

- Doug