Contributing to Octave Forge

GNU Octave (a.k.a. Octave core) provides the core language, while Octave Forge provides packages for it. For example, the image, control, signal, and statistics packages are part of Octave Forge.

For contributions to Octave core please see its Octave Developers Page. To contribute to Octave Forge, please read on.

Contributing to Octave Forge in general

A list of requested general contributions to Octave Forge is contained in Octaves task tracker, consisting of the tasks assigned to octave-forge.

If you'd like to make a general contribution, or if you think that a further task should be listed, please contact the Octave maintainers mailing list.

Taking over maintenance of existing packages

Currently unmaintained packages are listed here at our packages page. Additionally, new maintainers or co-maintainers are sought for the following community packages:

If you think you could help with package maintenance, or if you think that a further package should be listed here, please contact the Octave maintainers mailing list.

Contributing to existing packages

Each Octave Forge package (with exception of some old packages) has its own repository. Most use Mercurial although a few prefer Git. To contribute to a community package:

  1. Clone the package;
  2. Create a patch;
  3. Submit it to the correct tracker: the bug tracker if it fixes a bug, otherwise the patch tracker.

To contribute to an external package, contact the package administrator for the suitable procedure.

Cloning a package

The package list and the overview pages of each package contain links to web interfaces of the respective code repositories. There, a command line example for cloning the repository is given.

Creating a patch

After cloning the most recent version of the package, make your desired changes to the package code. Once all changes are complete, in the main package folder:

  1. Update the working directory;
  2. Commit changes;
  3. Export the changes to a patch file.

Submitting a patch

Submission is the same for both types of repository and identical to the process for Octave core. Submit the patch to either the patch tracker or the bug tracker, and wait for it to be reviewed. Another option is to host a clone of the package wherever desired and request a pull on the patch tracker. It is also possible to submit a simple patch or a new modified file but creating a patch as described above greatly increases the review and acceptance time.

Contributing new packages

If you want to contribute with a new package, mention this on the Octave maintainers mailing list.

You should decide if you want your package to be a community or external package.

For a package to be hosted at Octave Forge there are certain requirements.

The general structure of a package is described in the Octave manual.

Additionally, in Octave Forge packages:

Octave Forge maintains an example package which provides possible solutions for some common problems. It is a work in progress. There are no releases for this package. Its repository is here.

Making a package release

The details of the release procedure depend to some degree on the structure of the package.

For more information

Project history

Octave Forge was originally an Octave distribution. There were no individual packages and everything was a single repository, with everything released at the same time. The original distribution had 3 parts: main, extra, and non-free. An extra directory in the repository was also available for admin.

This became unmanageable which led to the creation of individual packages, released at different times as each package manager saw fit. They were still all under a single giant SVN repository (although with SVN one can easily clone only a subdirectory).

The non-free section was eventually removed, and two prerequisites were defined for inclusion of code in Octave Forge: a GPL compatible license and non-dependency on GPL incompatibility code.

With the increase of use of distributed version control systems, packages were slowly removed from the SVN repository and moved into individual Mercurial repositories. Not all packages have migrated, but only older packages, usually unmaintained, are still in SVN.