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