[ANN] Connectors for Squeak 4.2

> I am pleased to announce that Ned Konz's original Connectors has been
> updated for Squeak 4.2, is now available on SqueakSource under the
> "Connectors" project.
>
> I went through every method override from the Connectors 3.8 version and either:
>
>  - gave it back to Morphic or EToys packages, because it was
> identical to the current 4.2 method
>  - updated or integrated the 4.2 method, because the Connectors
> version was improved
>
> After doing this we are down to just 3 methods in Morphic that are
> overridden after loading Connectors and 2 in EToys.  Of course it
> would be nice if someone can figure a way to unify these last 5 but
> even so, it is much better than dozens of method changes.
>
> Connectors was originally deployed as a SAR file, and imported several
> bitmap images into the Image Imports of Squeak.  However, I do not
> believe these were used or, if they are, can be loaded separately.
> Connectors provides very useful functionality without those bitmaps,
> so we should be able to employ Monticello as Connectors SCM tool going
> forward.
>
> I have given the SqueakSource project world read and update, but
> reserved admin rights to myself, Bert, and anyone else who requests
> it.  I believe this is a good approach for our small community by
> balancing easy contribution with control.
>
> - Chris
>

> I am pleased to announce that Ned Konz's original Connectors has been
> updated for Squeak 4.2, is now available on SqueakSource under the
> "Connectors" project.
>
> I went through every method override from the Connectors 3.8 version and
> either:
>
>   - gave it back to Morphic or EToys packages, because it was
> identical to the current 4.2 method
>   - updated or integrated the 4.2 method, because the Connectors
> version was improved
>
> After doing this we are down to just 3 methods in Morphic that are
> overridden after loading Connectors and 2 in EToys.  Of course it
> would be nice if someone can figure a way to unify these last 5 but
> even so, it is much better than dozens of method changes.
>
> Connectors was originally deployed as a SAR file, and imported several
> bitmap images into the Image Imports of Squeak.  However, I do not
> believe these were used or, if they are, can be loaded separately.
> Connectors provides very useful functionality without those bitmaps,
> so we should be able to employ Monticello as Connectors SCM tool going
> forward.
>
> I have given the SqueakSource project world read and update, but
> reserved admin rights to myself, Bert, and anyone else who requests
> it.  I believe this is a good approach for our small community by
> balancing easy contribution with control.
>
>  - Chris

> I am pleased to announce that Ned Konz's original Connectors has been
> updated for Squeak 4.2, is now available on SqueakSource under the
> "Connectors" project.
>
> I went through every method override from the Connectors 3.8 version and either:
>
>  - gave it back to Morphic or EToys packages, because it was
> identical to the current 4.2 method
>  - updated or integrated the 4.2 method, because the Connectors
> version was improved
>
> After doing this we are down to just 3 methods in Morphic that are
> overridden after loading Connectors and 2 in EToys.  Of course it
> would be nice if someone can figure a way to unify these last 5 but
> even so, it is much better than dozens of method changes.
>
> Connectors was originally deployed as a SAR file, and imported several
> bitmap images into the Image Imports of Squeak.  However, I do not
> believe these were used or, if they are, can be loaded separately.
> Connectors provides very useful functionality without those bitmaps,
> so we should be able to employ Monticello as Connectors SCM tool going
> forward.
>
> I have given the SqueakSource project world read and update, but
> reserved admin rights to myself, Bert, and anyone else who requests
> it.  I believe this is a good approach for our small community by
> balancing easy contribution with control.
>
>  - Chris
>
>

> I am pleased to announce that Ned Konz's original Connectors has been
> updated for Squeak 4.2, is now available on SqueakSource under the
> "Connectors" project.
>
> I went through every method override from the Connectors 3.8 version and either:
>
>  - gave it back to Morphic or EToys packages, because it was
> identical to the current 4.2 method
>  - updated or integrated the 4.2 method, because the Connectors
> version was improved
>
> After doing this we are down to just 3 methods in Morphic that are
> overridden after loading Connectors and 2 in EToys.  Of course it
> would be nice if someone can figure a way to unify these last 5 but
> even so, it is much better than dozens of method changes.
>
> Connectors was originally deployed as a SAR file, and imported several
> bitmap images into the Image Imports of Squeak.  However, I do not
> believe these were used or, if they are, can be loaded separately.
> Connectors provides very useful functionality without those bitmaps,
> so we should be able to employ Monticello as Connectors SCM tool going
> forward.
>
> I have given the SqueakSource project world read and update, but
> reserved admin rights to myself, Bert, and anyone else who requests
> it.  I believe this is a good approach for our small community by
> balancing easy contribution with control.
>
> - Chris
>

> From: Bert Freudenberg <[hidden email]>
> Date: 5. März 2010 04:57:52 GMT-08:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Trunk repo and upstream packages (was Re: ConnectorsFor3dot11 for share)
>
> On 05.03.2010, at 00:00, David T. Lewis wrote:
>>
>> On Thu, Mar 04, 2010 at 05:55:07AM -0200, Edgar J. De Cleene wrote:
>>>
>>> On 3/3/10 11:15 PM, "David T. Lewis" <[hidden email]> wrote:
>>>
>>>> Well, kudos to the Etoys developers for taking custody of Connectors
>>>> and making it widely available. Obviously they had no reason to worry
>>>> about packaging for Monticello back when this was done, and I expect
>>>> that everyone will now agree that moving Connectors into a package
>>>> named "Connectors" would be a good idea for the future.
>>>>
>>>> I do think that it would be good to make Connectors easily loadable
>>>> (and unloadable) in Squeak trunk. This should soon be easier to do,
>>>> as the Etoys developers are moving to use Monticello and are now
>>>> hosting this work on source.squeak.org.
>>>
>>> I take care to put all Connectors .mcz into Ladrillos, still nota a
>>> MCConfiguration.
>>>
>>> I could made a Connectors package into squeaksource and move all to this
>>> place if some more wish become  ' Connectors Friends ' informal team.
>>>
>>> What you think?
>>
>> Edgar, good idea.
>>
>> Bert, from the point of view of the Etoys developers, would there be
>> a preferred place to host the Connectors package? In other words, is
>> it better to start a project on SqueakSource for Connectors, to leave
>> in hosted in source.squeak.org/etoys, or perhaps consider putting it
>> in source.squeak.org/trunk?
>>
>> Dave
>
>
> Good question, and it warrants a general policy discussion IMHO.
>
> In short - if someone stepped up to maintain Connectors as an independent project, then SqueakSource would be the right place for the master copy (called "upstream" in the open-source world). But independent of that, there still will be a copy in the Etoys repo, and in Trunk. I'll explain.
>
> When building an Etoys release we can not depend on any external whims. I'm sure that's the same for any company building a product. They will have a local copy of all the packages, and they will be very careful when upgrading the packages from external sources.
>
> Now normally this process is invisible, the public does not see these local copies. In the case of Etoys, the process of taking in new versions, and possibly patching them to fit into the product, happens in the open. So it looks like we, the product developers, choose to "fork" a package and maintain our "own" versions - when in reality it's just the only sensible thing to do if you need to build a stable release.
>
> For Trunk it's not quite as clear-cut but I'd still argue it would be good practice to have known-good versions in the Trunk repo, even if there are independent "upstream" repositories. This is because Squeak is not an independent project, but more like a distribution of packages. It's definitely needed to have local versions for some crucial pieces of infrastructure like Monticello. For optional packages like Connectors IMHO it would still be good to know exactly which version will work with a specific release - and the simplest way to do that is by keeping a copy in the Trunk repo and the "kitchen-sink" image.
>
> The trick and challenge is to establish a culture of not keeping local modifications for ever, but get them "upstream" as soon as possible, so the differences are minimal. We tend to not be really good about that. But then again this is a problem all over the open-source world. The best we can do IMHO is to strive for getting changes upstream, but not let this impede our own progress.
>
> - Bert -
>
>