Contributing to OpenAxiom

The OpenAxiom developers highly encourage individuals (researchers, teachers, students, etc) as well as organizations to contribute to the development of OpenAxiom, in form of new algorithms, libraries, new features, bug fixes, documentations, web page improvements, etc.

Legal Prerequisites

OpenAxiom is an open source software under a BSD-type license described here.

Submitting Patches

Every patch must have several pieces of information, before it can be properly evaluated:

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 and any existing testcases for the problem in the OpenAxiom testsuite.
If you cannot include testcases, you should include a justification for why adequate testcases cannot be added.
A ChangeLog entry as plaintext; see the various ChangeLog files for format and content, GNU Coding Standards for further information. The ChangeLog entries should be plaintext rather than part of the patch since the top of the ChangeLog changes rapidly and a patch to the ChangeLog would probably no longer apply by the time your patch is reviewed.
Bootstrapping and testing.
State the host and target combinations you used to do proper testing, and the results of your testing.
The Patch Itself.
If you are accessing the SVN repository at, please configure your svn to use GNU diff and generate patches using the "-p" or "-up" options. See SVN setup instructions for more details. If your version of diff does not support these options, then get the latest version of GNU diff. Patches against current development (SVN trunk) are preferred to patches against releases, unless your patch is intended as a candidate for the release branch.

Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts. In particular, changes to code formatting to conform to coding standards are best not mixed with substantive changes, because that makes it difficult to see what the real changes are. (In the case of a very large reorganization of code, it may make sense to separate changes even further to make it clearer what has changed; for example, by first sending structural changes that make subsequent changes easier but do not change OpenAxiom's behavior, then new code, then the changes that actually make use of the new code and change OpenAxiom's behavior.)

When you have all these pieces, bundle them up in a mail message and send it to