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
|