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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher danielv@netvision.net.il wrote:
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.
Looks like we're already seeing the potential for problems with removal code; macroBenchmarks interacting with vm code remove, games remove etc.
I guess we just need to stay aware of the potential for now since this is a phase that ought to be over reasonably soon. I hope. As we incorporate the assorted removals we can (I think) remove the items from the SM list. If we do that at least we can avoid future problems when somebody tries to use an out of date removal script.
tim
Daniel Vainsencher wrote:
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.
Actually, that's not a big deal... for some reason I was thinking that we were encouraging separate refactoring packages.
I guess the more important thing is that we should encourange the resulting maintained packages to not overwrite methods if possible. This will mean that the pre-removal refactoring did its job. In practice, though, this may not always be possible.
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.
Right. By tool support, you mean things like adding the warning?
- Doug
squeakfoundation@lists.squeakfoundation.org
-
Daniel Vainsencher -
Doug Way -
Tim Rowledge