[Squeakfoundation]3.6 MasterPlanner!?

[Doug Way]

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