Contributing to Octave Forge
GNU Octave (aka 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 it's page. To contribute to Octave Forge, please read on.
Contribute to existing packages
Each Octave Forge packages (with exception of some old packages) have their repository. Most use mercurial although a few prefer git. If you wish to contribute to an Octave Forge, you must first clone the package first. You can see the list of repositories here and here.
The rest of the process is the same as Octave core. After cloning, create a patch, submit it to the patch tracker, and wait for it to be reviewed. If you prefer, you can also host your clone of the package wherever you prefer and ask for a pull a request on the patch tracker.
You can also submit a simple patch or a new modified file but that will increase the review and acceptance time a lot.
If you want to contribute with a new package, you should mention it on the maintainers mailing list.
Octave Forge was originally an Octave distribution. There was no individual packages and everything was a single repository, 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 requesites were added 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 VCS, packages were slowly removed from the SVN repository and moved into individual mercurial repositories. Not all packages have migrated, and only older packages, usually unmaintained exist there now.
Making a package release
The details of this is very much dependent on the structure of the package.
- bump the Version number and Release date in the package DESCRIPTION file, update the NEWS and INDEX file, and the version in configure.ac file. Commit with "maint: release x.y.z"
tag the commit with
hg tag "release-x.y.z"
- run any bootstrap or autogen.sh script in the package.
produce a tarball of the package and take note of its md5 checksum:
$ cd your-package-directory $ hg archive --exclude '.hg*' somewhere/pkgname-x.y.z.tar.gz $ md5sum somewhere/pkgname-x.y.z.tar.gz
test everything worked fine by installing the generated tarball
pkg install somewhere/pkgname-x.y.z.tar.gz
make sure you have the latest version of the generate_html package
pkg install -forge generate_html
generate the function reference HTML files with the command
pkg load generate_html generate_package_html ("pkgname", "pkgname-html", "octave-forge")
produce a tarball of the HTML, and take note of its checksum:
$ tar cvzf pkgname-html.tar.gz pkgname-html $ md5sum pkgname-html.tar.gz
- Post the package, html docs and md5 checksums to the package release tracker asking for review and upload it on the server. Once its accepted, an Octave Forge admin will upload and make the announcement on the mailing list.