All Octave's sources are distributed under the General Public License (GPL). Currently, Octave uses GPL version 3. For details about this license, see http://www.gnu.org/licenses/gpl.html. Therefore, whenever you create a new source file, it should have the following comment header (use appropriate year, name and comment marks):
## Copyright (C) 1996-2011 John W. Eaton <jwe@octave.org>
##
## This file is part of Octave.
##
## Octave is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public
## License as published by the Free Software Foundation;
## either version 3 of the License, or (at your option) any
## later version.
##
## Octave is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied
## warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
## PURPOSE. See the GNU General Public License for more
## details.
##
## You should have received a copy of the GNU General Public
## License along with Octave; see the file COPYING. If not,
## see <http://www.gnu.org/licenses/>.
Always include commit messages in changesets. After making your source changes, record and briefly describe the changes in your commit message. You should have previously configured your .hgrc (or Mercurial.ini on Windows) with your name and email, which will get automatically added to your commit message. Your commit message should have a brief one-line explanation of what the commit does. If you are patching a bug, this one-line explanation should mention the bug number at the end. If your change is small and only touches one file, this is typically sufficient. If you are modifying several files or several parts of one file, you should enumerate your changes roughly following the GNU coding standards on changelogs, like the following example:
look for methods before constructors
* symtab.cc (symbol_table::fcn_info::fcn_info_rep::find):
Look for class methods before constructors, contrary to matlab
documentation.
* test/ctor-vs-method: New directory of test classes.
* test/test_ctor_vs_method.m: New file.
* test/Makefile.am: Include ctor-vs-method/module.mk.
(FCN_FILES): Include test_ctor_vs_method.m in the list.
In this example, the names of files is mentioned, and in parentheses the name of the function in that file that was modified. There is no need to mention the function for m-files that only contain one function. The commit message should describe what is changed, not why. Any explanation of why a change is needed should appear as comments in the code, particularly if there is something that might not be obvious to someone reading it later.
When submitting code which addresses a known bug on the Octave bug tracker (http://bugs.octave.org), please add '(bug #XXXXX)' to the first line of the commit messages. For example:
Fix bug for complex input for gradient (bug #34292).
The preferred comment mark for places that may need further attention is FIXME.