Voluntering to be the integrator of the Full Image

Doug Way dway at mailcan.com
Sat Aug 21 07:45:20 UTC 2004


On Thursday, August 19, 2004, at 09:06 AM, Marcus Denker wrote:

> Hi,
>
> We discussed that some more at lunch... and we think that one thing is 
> realy important: We need to think
> carefuly about the properties of the packages that we want (and don't 
> want) for packages in full:
>
> 1) Multi Plattform. It makes no sense to add a package that only works 
> on windows (that one was simple)

Agreed.

> 2) No changes to 3.7.
>
> This is important: A package in full has to be a package that is 
> purely add-on. If it changes the base system, we
> would get a image that is not 3.7 anymore.
>
> So packages that are included can add methods and classes, but they 
> shouln't change methods. It would be nice
> to have no changed methods at all. Maybe that will not be possible at 
> first, but it clealy should be the goal...

Definitely agreed with this.  Overwritten methods in packages are a 
frequent source of bugs.  (Often when the overwritten method is changed 
(via the update stream) in the base image but not changed in the 
package.)  Add-on methods rarely have these problems.

Any package which is "blessed" enough to be a Full package should 
arguably be able to get required changes made in the base image (or in 
prerequisites) so that overwriting methods isn't needed.

It'd be interesting to see which of the current packages in the 3.7 
Full Assembler overwrite methods, and how many methods.  (I could try 
this... the ConflictChecker shows overwritten methods as a side 
effect.)  We might have to tolerate a few overwritten methods, but any 
package which overwrites a lot of methods, we should seriously consider 
not including.

> And in the long run, we should investigate if it is possible for a 
> package to change the system privately in a way
> that this change is only visible for that package.
>
> Alexandre has some very nice experiments in that direction (aka 
> ClassBoxes).

Yeah, that's more long-term... :)

- Doug




More information about the Squeak-dev mailing list