[Squeakfoundation]3.6 MasterPlanner!?
Doug Way
dway at riskmetrics.com
Sun Apr 6 00:14:55 CEST 2003
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
More information about the Squeakfoundation
mailing list