[Squeakfoundation]3.6 MasterPlanner!?

[Daniel Vainsencher]

I agree that we should make sure removal of a package doesn't break
either it or other stuff in the image.

I don't know whether there's a point in separating the refactorings from
the removal package. After all, the removal package is supposed to get
rolled into the updatestream.

The Celeste removal does the refactorings required and then removes the
package, which seemed reasonable to me at the time. If someone thinks
this is a problem, I don't mind reworking it so refactorings and
removals are separate.

Other quality criteria - we should encourage package maintainers to
never override code, but we can't enforce it. Right now, there isn't
even a warning when loading a package that overrides code. We should
provide the tool support first, start pushin the rule later.

Agree on Accufonts now, further developments later.

Daniel

Doug Way <dway at riskmetrics.com> wrote:
> 
> 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
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation