ConnectorsFor3dot11 for share

Just for some wishing Connectors on Trunk..
I proud announce add missing postscript to my previous ConnectorsFor3dot10-188.sar.
I made for Smalltalks 2007 and show the first FunSqueak with all ‘old friends’ packages to audience.

Ned Konz is still the owner on SqueakMap and no Co-maintainers , not sure how share this so any wishing it send mail to [hidden email].

Stephane , I took this as last muO, have some more recent?
http://map.squeak.org/accountbyid/5f9bef44-1fbb-4dd6-8f10-a69862ad5674/files/muO.232.sar

Edgar

> Stephane , I took this as last muO, have some more recent?
> http://map.squeak.org/accountbyid/5f9bef44-1fbb-4dd6-8f10-a69862ad5674/files/muO.232.sar

This is the more recent public version indeed. I'm rather close to
release 234 but it still has to go through extensive bug tracking and
documentation update. Maybe next week...

Stef

On 3/3/10 9:46 AM, "Stéphane Rollandin" <[hidden email]> wrote:

> This is the more recent public version indeed. I'm rather close to
> release 234 but it still has to go through extensive bug tracking and
> documentation update. Maybe next week...
>
> Stef

Ok.

I exploring the .sar and the pre requisites for see the list of packages.
Once thing I miss is the Replugin for Mac OS X Intel, if you have it or know
where is ready to run, please tell.

All this is a good exercise to discover bugs , things which could be
improved or changed and one more travel to packages Laberynt.

I only focus on load all and have it working as close as was in 3.8.
Then you do your magic

Edgar

Bravo Edgar!  Connectors is a great package that should be allowed to
slip through the cracks.

> Ned Konz is still the owner on SqueakMap and no Co-maintainers , not sure
> how share this so any wishing it send mail to [hidden email].

I would definitley like to obtain a copy and test it with Maui.  If we
can't get access to the existing project, perhaps we could create new
SqueakMap package, "Connectors3.11" or something like that?

 - Chris

Hi,
in the Etoys image we have integrated Connectors into the Etoys package.
I'm not sure if it was the right thing to do, it's a big codebase and
makes Etoys even bigger.

Karl

On Wed, Mar 3, 2010 at 4:09 PM, Chris Muller <[hidden email]> wrote:

Hmm, Connectors is a generic package, so I'm not sure why such an
integration would be done..?   :-(

On Wed, Mar 3, 2010 at 9:16 AM, karl ramberg <[hidden email]> wrote:

On Wed, Mar 03, 2010 at 09:28:54AM -0600, Chris Muller wrote:
> On Wed, Mar 3, 2010 at 9:16 AM, karl ramberg <[hidden email]> wrote:
> > Hi,
> > in the Etoys image we have integrated Connectors into the Etoys package.
> > I'm not sure if it was the right thing to do, it's a big codebase and
> > makes Etoys even bigger.
>
> Hmm, Connectors is a generic package, so I'm not sure why such an
> integration would be done..?   :-(

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.

Dave

On 3/3/10 11:15 PM, "David T. Lewis" <[hidden email]> wrote:

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

On 04.03.2010, at 02:15, David T. Lewis wrote:
I guess we were not aware people were interested in using Connectors without Etoys. But I agree, breaking out any package that is "interesting" in its own right is a Good Idea.

- Bert -

On Thu, Mar 04, 2010 at 05:55:07AM -0200, Edgar J. De Cleene wrote:
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

On 05.03.2010, at 00:00, David T. Lewis wrote:

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 -

Bert Freudenberg skrev 2010-03-04 12:43: Ok,
here is first commit of the Connectors from Etoys
http://source.squeak.org/etoys/Connectors-kfr.1.mcz

Karl