[squeak-dev] Trunk repo and upstream packages (was Re: ConnectorsFor3dot11 for share)

Bert Freudenberg bert at freudenbergs.de
Fri Mar 5 12:57:52 UTC 2010

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" <lewis at mail.msen.com> 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 -

More information about the Squeak-dev mailing list