We strongly encourage individuals as well as organizations to contribute to the development of GNU Smalltalk, in the form of better portability, new packages or improvements to the existing ones, bug fixes, documentation updates, web page suggestions, etc.
A short task list is available in the issue tracking system. Any other contribution, however, is welcome.
The technical information in the Hacker's guide will help you developing GNU Smalltalk itself (as opposed to developing with GNU Smalltalk). The rest of this page includes administrivia that might be less interesting, but are as important.
All contributions must conform to the GNU Coding Standards. For submissions which do not conform to the standards we may request (depending on the size of the submission) to address any such problems.
For documentation changes you should perform make info and make dvi and correct any errors. You should investigate complaints about overfull or underfull hboxes from make dvi, as these can be the only indication of serious markup problems, but do not feel obliged to eliminate them all.
Every patch must have several pieces of information:
- A description of the problem/bug and how your patch addresses it:
- For new features a description of the feature and your implementation. For bugs a description of what was wrong with the existing code, and a reference to any previous bug report.
- A ChangeLog entry as plaintext can be useful for submissions that are not extremely small; see the various ChangeLog files for format and content, and the GNU Coding Standards for further information. The ChangeLog entries should be plaintext rather than part of the patch
- The patch itself:
- Please generate patches using the "-up" options. If your version of diff does not support these options, then get the latest version of GNU diff.
- Repository (optional):
- If you have established a public Git repository, please include the branch name (and if this is your first contribution, the URL to the repository) for the patch being submitted, as this will simplify integration of your patch.
Don't mix together changes made for different reasons. Send them individually.
We prefer patches posted as plain text or as MIME parts of type text/x-patch or text/plain, disposition inline, encoded as 7bit or 8bit. It is strongly discouraged to post patches as MIME parts of type application/whatever or disposition attachment.
When you have all these pieces, bundle them up in a mail message and send it to the mailing list.
In order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.
If you are contributing non-trivial amounts of code to GNU Smalltalk, you will be asked to sign a copyright assignment form provided by the FSF.