Stef, please correct me if I wrote something incorrect :) Hi folks. It is since a couple of months that we have been discussing with Stef about the current Pharo architecture and the different kind of images we have. What we want to achieve, is to have a really small kernel and provide Metacello configurations so that people can easily load the rest of the stuff. Similar to what we are already doing with PharoCore and PharoDev. However, this still have limitations: 1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ? 2) Most of the Pharo external packages that are loaded in a Dev image, are maintained by their own developers, not necessary "Pharo developers". So, we want to define "something" that Pharo developers should maintain, but that are not part of the core, neither a dev tool. For example, suppose that we want to remove some messages, classes or whatever, when we look senders or references, we should do it now not only in the core, but also in this new image. This is because now Pharo developers, will take care also about this. We don't have yet a clear name for this image. Do you have? We created a new repository called PharoNonCorePackages in squeaksource, and there we put all the packages that are part of this new concept. In addition, we created a Metacello configuration for that. With this, Pharo developers will be able to easily load that configuration in a PharoCore image. The name of such package is ConfigurationOfPharoCore, but I am not sure I like the name. Do you have a better one ? Of course, the Dev image will also have this configuration as reference, it means, the dev image will also have this stuff. We think this will let us have a smaller kernel, but still maintaining non core stuff in separate packages and easily loadable. It will also lower the "fear" when making a package external. The last thought was how we can integrate Metacello to manage updates in the system update. This is still green, but would be cool to a future. The idea is to migrate the ScriptLoader stuff, and instead, releasing metacello versions. Then, the system update should be just to load the last metacello version. So...what do you think ? Cheers