On 2006 August 28 10:50, Giovanni Giorgi wrote:
> I have little time but I am a Software Architect.
> So if you (=the community/board directors)  like I can draw some
> guidelines for the SqueakCore project.
> For instance we can draw together some basic rules for API
> deprecation, unit testing and so on.

Hi Giovanni,

Thanks for commenting, and sorry for my late reply, I marked this thread as 
"todo", but then never looked back until now, with discussions about 
Strongtalk, I remembered I left something on my "todo/reply" that is related.

I do not have much to add, while I continue liking the idea of defining 
modularity and well-defined interfaces (and possible interchangeability) 
between VM[Current, Pepsi, Strongtalk]<-->Core[Current, Spoon]<-->Packages, 
(which themselves would be loadable/unloadable starting with the "lowest 
level" such that Tweak/Morphic/NativeUI), I am simply not qualified enough to 
drive such SqueakCore effort, or have enough time to help significantly. 
Having said that, if someone, or the board, goes this direction, and such 
modularization effort is established, I will try to participate and help to 
the best I can (which may amount to well below 1 cent :) )

Milan

> Drop me an email  :-)
> My 4 cents (yes I am a bit more  rich :)
>
>
> On 8/26/06, Milan Zimmermann <milan.zimmermann at sympatico.ca> wrote:
> [...]
>
> > Yes that makes sense. I felt uneasy commenting on this given I am barely
> > a weekend squeaker, but got encouraged by the original question "what
> > would it take for you[squeak-dev list member] to "buy in" to a central
> > governance model for Squeak".
> >
> > > Also, Squeak would continue to evolve the Squeak we know.  Discussions
> > > about tossing it and starting from the ground up are interesting but
> > > off topic.  If you want to do that, then you are free, but Squeak's
> > > organization should take care of Squeak.
> >
> > What I had intuitively in mind (by saying it would make sense to
> > encourage alternative cores) would be their existence would show the API
> > to the core is well-defined and hopefully stable. In a way similar to
> > ability to run (a large set of) packages such as KDE on both Linux and
> > FreeBSD shows there must be well-understood API to the cores (perhaps
> > with different adapters but still defined).  Apart from that
> > clarification I agree talking about alternatives was off-topic.
> >
> > Milan