links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
How to contribute to Squeak
Last updated at 2:42 pm UTC on 8 March 2020
Squeak is maintained by volunteers around the world using a simple community driven process known as the Development Process

Contributions may take different forms.
See section below for detailed steps.

Squeak has a built-in package management tool called Monticello that makes it very easy to gather and upload a ChangeSet to repositories.

Many packages also use Monticello for version control. It started with http://www.squeaksource.com/ as the repository which is still in use. Newer projects are hosted at SmalltalkHub and SqueakSource3 (ss3).

Contributing to the Base system

If you want to contribute an improvement you can submit it to the Inbox repository. Developers on the squeak-dev mailing list will be notified and the change might be discussed there. Accepted changesets are merged into the main trunk by Core Developers and the rest are moved to Treated repository.

Contributing Bug Fixes

Contributing a package

SqueakMap If you write a cool package, this is where you should place it. This catalog allows anyone to install your code easily from Squeak.

Detailed steps for submitting a changeset to the Squeak Trunk Version

... adapted from Dave Lewis post in squeak-dev mailing list

At any given time, there will be a release version and a trunk version listed in Squeak Downloads. Changes may be proposed to the latest version under development by following the steps below.

  1. Create an account on source.squeak.org
  2. Open the inbox repository
  3. Verify the differences between your image and the latest version in the trunk repository:
  4. Submit your changes to the inbox
  5. Follow ups

A good commit message should state what was changed, why and possibly include a small code snippet to explain the reason for the change. Someone, a few years down the line, should be able to read the patch and understand why the change was made. See http://forum.world.st/The-Trunk-Compiler-eem-387-mcz-tp5079866.html for an example.

Merging Commits from the Inbox by Core Developers

If a change in the inbox is accepted the following should be done by a core developer to merge it:
  1. Merge the commit in an up-to-date trunk image
  2. Make sure the commit works with the up-to-date image
  3. Commit the merged state
  4. The merge commit has now two ancestors: the previous head of the trunk repository and the commit from the inbox. To provide a consistent history, we have to move the inbox commit to the trunk repository. Therefore go to Inbox and look for the commit under versions. After clicking on the version you see details of the version and two buttons which allow you to move the version either to trunk or the treated inbox. Use the move to trunk button to move the change to the trunk.
In case there are no new commits in the trunk repository, core developers can also simply use the "Move to Trunk" button on http://source.squeak.org/inbox.

If a changeset (say badfix.101) has been merged into trunk from inbox and later discovered to be defective, then
  1. Create a new changeset (say goodfix.102)
  2. Create a new merge (say mergedfix.105) that contains the fix and has both badfix.101 and goodfix.102 as ancestors
This will preserve the history for those who would have upgraded from the trunk meanwhile.

Guidelines for Core Developers for Trunk submissions:

  1. Give your peers a chance to review, commit to the Inbox first.
  2. Regard the code repository and ancestry with equal respect to the image, for example, by avoiding unnecessary litter and bloat.
  3. Never only change formatting, and even avoid changing prior developers formatting when making only minor changes to a method.
  4. Never commit same-day code. Think about it and live with it for at least a few days first.
  5. Only commit meaningful changes like a fix or improvement, not merely a spelling or comment fix. Gather those up to include next time there is a bigger change to that package.
  6. Before moving something from Inbox to Trunk, please re-adopt the version in trunk as the ancestor, so the ancestry will not be bloated with all of the interim attempts – the goal is one version per change.
Note: The "Adopt" button currently produces an intimidating message, but it's really okay to use in this instance.
  1. If you mess up, and its still the top version, revert to the prior version before applying the fix.

  1. When saving the MCZ version,

Repository Locations