Hi, I tried to follow the discussion on both lists regarding supported packages and how/where to manage them by using Metacello. I can not give complete feedback since I go with Göran here who said "I need to read your thoughts once more before giving proper feedback." and I think we all should take the time to think about all the implications the different approaches have. With this discussion we set up the base for the future of package maintenance but also for collaboration amongst the communities, how images are built, ...! I'm sure we all want to blur the line between in and out of the (whatever) image and share/reuse as many code/packages as possible within the broader community (Squeak, Pharo, Cuis, Gemstone, ...). So: Goal Nr. 1 is: if it is not in my environment then just load it. Goal Nr. 2 is: if it is loaded it should work in my environment since it brings in anything it needs to work Currently the discussion and actions seem to focus on where to put the configurations (into the image vs. in repositories per version). I'm in favour of the latter since that is easier to handle and share between platforms while having them in the image would limit people who work on various platforms, it would not scale and eat more resources for maintenance. My fear is also that if you have the configurations within the image then we all will end up with something similar to the unmaintained SqueakMap registrations. With external repos we can also feed CI-Tools (Hudson build server, ...) The only benefit from the "maintining configs in-image" would be that it would be easy to build a UI similar to SqueakMap/Universe Browser. This is something that has to be solved - especially for Pharo since loading/browsing it is not very "user friendly" today, but AFAIK work already started with the "Loader" project. Agree with Andreas that Metacello needs more work and a good browser of available configs would be a plus. But thats not the main question. Even if Squeak decides to have the configurations "in-image" and Pharo decides for external configs one can mix them: An in-image ConfigurationOfMyApp just loads the ConfigurationOfMyAppExternal where the last one is maintained in an external repo and the internal config is for convenience to just load it. However - I have to reread all the arguments and think about all this. <warning> But with a better acceptance of Metacello there will be more to come and to discuss! </warning> Lets think about the implications for anything above the virtual machine: Squeak is currently maintained as a "full image" using the trunk process while Pharo already switched to a "small core + external packages" model. The "pharo core" image (which is not Pharo!) is getting stable and hopefully smaller and one can already create a Pharo image right from the "ConfigurationOfPharo". That is there and working. I'm not saying that Squeak is not getting stable (I'm still a Squeak AND Pharo guy) but it is a different approach to build the end result that we later announce on our websites. If Squeak jumps on the Metacello config bandwagon it may also have to think about jumping onto the "small core + external packages" model. At least to me this would be the next logical step. This leads to several questions: - could this small core could be the same for all of us - especially since we currently fix stuff in Cuis, Squeak and Pharo mostly the same way - could this small core be reduced to a minimum set of objects and a loader that is able just suck in the things defined in package configurations of packages that work together - would any specific assembled/deployed image not just be a special distro of the "small kernel" + selected packages (similar to the linux world) So "Squeak" may later be the distro with media/fun/experimental packages or etoys and "Pharo" may later be the distro with packages oriented towards commercial development. However then the lines are blurred then and if you have the common core on your disk you can even create your own distro with Seaside and Etoys ... Pharo will follow the path "kernel" + selected packages" and external config path anyway since this is already discusssed and prepared.
From what I understand so far a repo for Pharo 1.1. will appear soon with freezed/working configs and a build structure will be set up. So lets see how this works out and if successfull if Squeak will adapt it too.
Just my 2 cents. Expect additionally cents after getting more time to think about all this ... Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01