Torsten

On 5/17/10, Torsten Bergmann <astares at gmx.de> wrote:
> 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.

Yes, I think this is good. At the same time it does not exclude to go
one with a trail Configuration Package within the Squeak image and see
how it works.

Today Colin P. put a Configuration of OmniBrowser with refactoring
into the Inbox.
I checked it out and it looks good. I did not thorough testing though.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150721.html


>
> 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,
> ...!

Yes

> 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:

Great that you mention Cuis and Gemstone in addition.
This will open up a lot of opportunities.

> 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

Thanks for reminding us of the basics. And that there is a need for
doing so is food for thought.... :-)

> 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.

I think we need both. A few (6...12) high profile
ConfigurationOfThePackageName (Or as Dale H. suggested and Andreas
proposed  'ThePackageNameInstaller') within the image and
for the rest the Metacello Repository.

For the ones within the image there should be some kind of checks that
they work together when everything is loaded together as well as that
all the tests (with a few exceptions) are green.

> 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.

I share this and for this reason I suggest that we limit the number
for the time being.

 With external repos we can also feed CI-Tools (Hudson build
> server, ...)

Yes.

> 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.

Yes, and that is quite important for a newcomer.

Iin analogy we have here the 'Synaptic' vs. apt-get install discussion.
In the long-run however it pays off to learn 'apt-get'.

> 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

An excellent idea! I like this. It says. The core developer have
approved a certain configuration for a certain package.

> where the last one is maintained in an external repo and the internal
> config is for convenience to just load it.

Yes.

> However - I have to reread all the arguments and think about all this.

Sure.

> <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.


Actually Squeak is in the process of getting smaller and more stable
as well.....


> 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


Sure, a good mid-term goal.

>   - 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


Maybe.

>   - would any specific assembled/deployed image not just be a special distro
>     of the "small kernel" + selected packages (similar to the linux world)


Yes.

> 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.

Yes, a good vision.

> 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.

I cannot comment on this because I do not follow Pharo closely for
time constraint reasons.

> Just my 2 cents. Expect additionally cents after getting more time to
> think about all this ...

This was more than just 2 cents. A carefully written mail.

Thank you

--Hannes