I would say, let's keep it simple.  If it's a package that is a port from another Smalltalk dialect, the Squeak version should be in the Squeak repository.  If it's a package that originates from Squeak and that other dialects are porting, let's keep the Squeak version into the Squeak repository.  If it's a package that no one cares about and it's for Squeak, let's keep it into the Squeak repository.  Just like the Cincom Public Repository : if it's code for VisualWorks, it's all there in ONE place.  If it<s code for Squeak, it should all be in one place.

Now, it's just a matter of "enhancing" our repository with package comments to say that package 1.2 for Squeak corresponds to version 3.4 of VisualWorks XStreams package.  Or version 0.2 of Nautilus for Squeak is in fact a port of the Pharo 1.2 version of Nautilus.  Or that AbtConverter 3.1 for Squeak is a port of  AbtConverter 7.4 of VAST.

But ALL the Squeak code in ONE place.


 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)


>________________________________
> From: Colin Putney <colin at wiresong.com>
>To: Benoit St-Jean <bstjean at yahoo.com> 
>Cc: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> 
>Sent: Thursday, December 20, 2012 2:54:23 PM
>Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
> 
>
>
>
>
>
>
>On Thu, Dec 20, 2012 at 2:40 PM, Benoit St-Jean <bstjean at yahoo.com> wrote:
>
>Hi Colin,
>>
>>Yeah, your idea makes sense, somehow...  But adding a layer, when it's clear that Pharo is deconstructing the "Squeak base" (its ancestor) piece by piece will make it hard.  At the rate at which they are deleting "squeak stuff" in the Pharo image, we'll all spend our time coding for this "compatibility/portability" layer.  Besides, can you imagine the mess that will result for projects that are cross dialect and that are already providing compatibility layers (Glorp, Seaside, etc) ???  Two layers of compatibility, really ???
>>
>>To paraphrase Fleetwood Mac, "you can go your own way" I'd tell the Pharo people.  I find it funny that Squeak's child (Pharo) is farther away from Squeak than VisualWorks can be these
 days...
>
>
>
>
> Well, I wasn't thinking of a Pharo compatibility layer, so much as a repository where we could store the "Squeak port" for packages that aren't developed natively on Squeak. (By "ports tree," I meant FreeBSD's ports system.)  So, for example, the Xtreams port from VisualWorks could live there, the Seaside port from Pharo, and so on.
>
>
>And of course, Frank is quite right, no technical solution like this is a substitute for communication with developers in other communities. But if we have a strategy for handling things like this, it can make that communication smoother. 
>
>
>Just a thought.
>
>
>Colin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121220/65212f69/attachment.htm