Developers
If you want to contribute to an existing package, please contact the package maintainer directly. Contact information is given in the list of packages.
If you want to contribute a new package, ask in Octave Discourse for help.
The remainder of this page is mostly outdated and only left for reference.
Code
The source code for each Octave Forge package is on its own individual mercurial or git repository. To clone all package repositories locally, we provide a meta-repository octave-forge.
The code of this website can be found in the repository project-web.
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
If you'd like to make a general contribution, please contact the maintainers mailing list.
Taking over maintenance of existing packages
Currently unmaintained packages are listed at our packages page. However, this list might not be up-to-date. If you think you could help with maintenance of a particular package, please step forward and contact the last known package maintainer or the maintainers mailing list.
Contributing to existing packages
Each Octave Forge package (with exception of some old packages) has its own code repository. Most use Mercurial although a few prefer Git. To contribute to a community-maintained package (those listed in the first group at the packages page):
- Clone the package
- Create a patch
- Submit it to the bug tracker or to the patch tracker
To contribute to an external package (those listed in the second group at the packages page), contact the package maintainer for the suitable procedure. External packages might use an external repository for primary package development. In this case the repository at Octave Forge only gets updated during package release and you should look elsewhere for the current development branch of the package.
Clone the package
The package list and the overview page of each package contain links to web interfaces of the respective code repositories. There, a command line example for cloning the repository is given.
Create a patch
After cloning the most recent version of the package, make your desired
changes to the code. Many packages provide a maintainer Makefile and you can
run the modified package locally with the command make run
to
test your changes in an interactive Octave session.
Once all changes are complete:
-
Update the working directory
hg pull && hg update
/git pull
-
Commit changes
hg commit
/git commit
-
Export the changes to a patch file
hg export -r tip
/git format-patch -1 HEAD
Submit the patch
Submit it to either the bug tracker if it fixes a bug, or to the patch tracker if it adds new functionality. Then wait for it to be reviewed. If the package maintainer is known, please add her/his address in the field Mail Notification CC to speed up the review.
Alternatively, you may host a clone of the package repository wherever desired and request a pull on the patch tracker. This is especially useful for larger changes. It is also possible to submit 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 maintainers mailing list. You should decide if you want your package to be community-maintained or external.
Community packages
Community packages are attempted to be coordinated between each other and with Octave. To facilitate this, their maintainers are expected to:
- cooperate, if asked, with Octave Forge in achieving and implementing decisions regarding the package. The maintainers voice will have a large weight, but decisions may sometimes even relate to name changes of functions, the inclusion of new functions into the package, or assigning of functions to a different package or to Octave.
- keep the Octave Forge clone of the package repository current.
- handle patches created against the currently developed heads at the Octave Forge repository, or pushed to the Octave Forge repository, by others. In occasional cases, a patch with only formal changes, or with a non-intrusive fix required to be compatible with new Octave versions, may be pushed by others (typically administrators) even without asking before.
External packages
Decisions on the content of external packages are solely in the authority of the package maintainer.
External repositories
Both community and external packages may of course have external clones of repositories where their maintainers accept contributions by others. Maintainers may publish releases outside Octave Forge, possibly under different package names. If releases at Octave Forge and outside of it have the same name and version, they should be identical.
Requirements for packages hosted at Octave Forge
Like Octave itself, the packages provided at Octave Forge are Free Software (free as in free speech).
Licensing
- The package code must be either in the public domain or covered by a Free Software License.
- Any code linking to GNU Octave (oct-files) must have a license compatible with that of GNU Octave (GPL3+).
- For community packages, all code is required to be under a license compatible with that of GNU Octave, or to be in the public domain.
- Any file containing non-trivial code must contain either a notice that it is in the public domain, or (better) a copyright and license notice.
- The functioning of the package must not depend on programs that are not Free Software.
Releases
- A release at Octave Forge must be reproducible from a corresponding revision present in the code repository at Octave Forge. The source files in this revision must be identical to the source files in the release.
- To facilitate reviewing, reproducing the release from the repository must be possible with a Makefile in the top level package directory. If possible, the template Makefile should be used.
Symbol uniqueness
Except if overwriting existing functions is intended, symbol duplications over function names, class basenames, and namespace (base)names should be avoided. Note that community packages may violate this rule by using symbols which are already defined in external packages; this can be necessary e.g. for Matlab compatibility.
The general structure of a package is described in the Octave manual. Additionally, in Octave Forge packages:
- Often a script src/bootstrap, e.g. to create src/configure, is included.
- General package documentation in the texinfo format may be included.
- A Makefile at the toplevel directory of the package is suggested, in particular to simplify the release procedure. A template Makefile is available.
-
The INDEX file needs special attention to enable checking for
symbol uniqueness among packages and Octave.
-
Class methods, even for classdef based classes, should be
listed as
@class_name/method_name
. -
Namespaced functions or methods should be listed without a
+
prefix:namespace.[sub_namespace. ...]function namespace.[sub_namespace. ...]@class_name/method_name
- If the package contains namespaces or classdef based classes, an INDEX file should be present.
- If an INDEX file is present, it should contain all function names, at least one method of each class, and at least one namespaced function of each namespace.
-
Class methods, even for classdef based classes, should be
listed as
-
The duplicate checker at Octave Forge should be used to check if a
symbol of the package is already defined by another package or by
Octave. After installing your package and the
generate_html package, you can use this
interface:
pkg load generate_html check_duplicates ("pkgname");
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.
Making a package release
The details of the release procedure depend to some degree on the structure of the package.
- Check the Version number and Release date in the package DESCRIPTION file, update the NEWS and INDEX file, and the version in the configure.ac file, if present.
- Commit and push to the Octave Forge repository.
-
For community packages, the released changeset will be tagged by
the Octave Forge administrator who puts the release online. In
external packages, the package maintainer is responsible for
tagging the released changeset with
release-x.y.z
; this should be only done after the release has been accepted. -
Make sure you have the latest released version of the
generate_html package
pkg install -forge generate_html
-
If possible, use the
template Makefile
of Octave Forge to generate the tarballs for the package
and its online documentation with
make release
. You may also customize this Makefile for your package or copy from a Makefile of another package with similar structure. -
The following steps are necessary in release generation, and are
typically performed by
make release
:- Running any bootstrap file of your package.
- Removing any created directories and files that should not be in the release.
-
Creating a tarball of the package and noting its md5
checksum. For Mercurial:
cd your-package-directory hg commit # if not already done hg archive --exclude '.hg*' somewhere/pkgname-x.y.z.tar.gz md5sum somewhere/pkgname-x.y.z.tar.gz
-
Testing that everything worked fine by installing the generated
tarball:
pkg install somewhere/pkgname-x.y.z.tar.gz
-
Generating HTML documentation with function references:
pkg load generate_html generate_package_html ('pkgname', 'pkgname-html', 'octave-forge')
As documented for generate_package_html (), custom package documentation in the texinfo format can be included into the online documentation. -
Generating a tarball of the documentation and noting its md5
checksum:
tar cvzf pkgname-html.tar.gz pkgname-html md5sum pkgname-html.tar.gz
- Post the package and documentation tarballs to the package release tracker, noting their md5 checksums. Once they are reviewed, accepted, and uploaded to the server, you can make an announcement at the mailing list.
For more information
- The Octave Wiki has a detailed page about developing for Octave using Mercurial, including a simple description of Mercurial queues.
- The Octave Wiki also contains detailed commit message guidelines.
-
There is a wealth of useful information in the GNU
Octave documentation. In particular,
- Appendix B describes the creation of test and demo functions,
- Appendix C offers tips and standards on writing clean code, and
- Appendix D, while primarily aimed at Octave core developers, gives good information on creating source files and changesets (patches). It also describes the use of Mercurial queues.
- The maintainers mailing list is another potential source of information for developers. Please only use this list if participating in Octave or package development.
Project history
Before 2007, Octave Forge did not even have packages since Octave did not had a package manager yet; all of Octave Forge was a single extension to Octave. Development of packages were concerted and releases were synced. Because of this, all development happened in a single repository, it was a single project.
Before February 2010, 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 legacy SVN repository was also available for admin.
As the number of packages increased it became too difficult to coordinate development of the packages, and with the introduction of a package manager in Octave there was no need for that either. This 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.
Eventually subversion became a burden as some packages preferred to have their main development happen somewhere else. Between 2013 and 2016, individual packages migrated their history from subversion to a DVCS such as mercurial and git. History of whole package development was migrated to the new repositories.