Contribute: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Bug reports and patch submission == | == Bug reports and patch submission == | ||
* Bugs and patches should be submitted to Octave's [https://savannah.gnu.org/ | * Bugs and patches should be submitted to Octave's [https://savannah.gnu.org/bugs/?func=additem&group=octave bug] and [https://savannah.gnu.org/patch/?func=additem&group=octave patch] trackers respectively. | ||
* The best way to contribute patches is to create a Mercurial changeset. | * The best way to contribute patches is to create a Mercurial changeset. | ||
** Learn how to use [[Mercurial]]. | |||
** [[Commit message guidelines]]. | |||
=== Contributor Agreement === | === Contributor Agreement === | ||
| Line 11: | Line 13: | ||
* Your contribution will be released under the terms of the GNU GPL, version 3 or any later version. | * Your contribution will be released under the terms of the GNU GPL, version 3 or any later version. | ||
* Your contribution must be an independent work or derived from code that may be released under the terms of the GPL. Under no circumstances may it be based on code from Matlab or other non-free code that you may have access to view. | * Your contribution must be an independent work or derived from code that may be released under the terms of the GPL. '''Under no circumstances may it be based on code from Matlab or other non-free code that you may have access to view'''. | ||
* In the Octave source code, all files are marked with a copyright statement that says "Copyright (C) YYYY-YYYY The Octave Project Developers". This copyright notice is used to ease the burden of maintaining copyright information in the source files, not to diminish or remove credit for contributions. Detailed information about what changes have been made and who has made them is maintained in the revision history of the Octave sources. | * In the Octave source code, all files are marked with a copyright statement that says "Copyright (C) YYYY-YYYY The Octave Project Developers". This copyright notice is used to ease the burden of maintaining copyright information in the source files, not to diminish or remove credit for contributions. Detailed information about what changes have been made and who has made them is maintained in the revision history of the Octave sources. | ||
| Line 25: | Line 27: | ||
Apart from C++ and Octave language (m-files), Octave's sources include | Apart from C++ and Octave language (m-files), Octave's sources include | ||
files written in C, Fortran, M4, Perl, Unix shell, AWK, Texinfo, and | files written in C, Fortran, M4, Perl, Unix shell, AWK, Texinfo, and | ||
TeX. There are not many rules to follow when using these other | |||
languages; some of them are summarized below. In any case, the golden | languages; some of them are summarized below. In any case, the golden | ||
rule is: if you modify a source file, try to follow any conventions you | rule is: if you modify a source file, try to follow any conventions you | ||
| Line 45: | Line 47: | ||
If you modify a Fortran file, you should stay within Fortran 77 with | If you modify a Fortran file, you should stay within Fortran 77 with | ||
common extensions like {{codeline|END DO}}. Currently, we want all sources | common extensions like {{codeline|END DO}}. Currently, we want ensure that | ||
it is possible to compile all sources with the gfortran compiler, without | |||
possible. This usually means that non-legacy compilers also accept the | special flags if possible. This usually means that non-legacy compilers | ||
sources. | also accept the sources. | ||
=== M4 guide === | === M4 guide === | ||
Latest revision as of 13:04, 13 August 2024
Bug reports and patch submission[edit]
- The best way to contribute patches is to create a Mercurial changeset.
- Learn how to use Mercurial.
- Commit message guidelines.
Contributor Agreement[edit]
By submitting patches to this project, you agree to the following conditions:
- Your contribution will be released under the terms of the GNU GPL, version 3 or any later version.
- Your contribution must be an independent work or derived from code that may be released under the terms of the GPL. Under no circumstances may it be based on code from Matlab or other non-free code that you may have access to view.
- In the Octave source code, all files are marked with a copyright statement that says "Copyright (C) YYYY-YYYY The Octave Project Developers". This copyright notice is used to ease the burden of maintaining copyright information in the source files, not to diminish or remove credit for contributions. Detailed information about what changes have been made and who has made them is maintained in the revision history of the Octave sources.
- If you wish, you will be credited as a contributor in the Octave documentation.
Building from development sources[edit]
- See Building.
Coding style[edit]
Apart from C++ and Octave language (m-files), Octave's sources include files written in C, Fortran, M4, Perl, Unix shell, AWK, Texinfo, and TeX. There are not many rules to follow when using these other languages; some of them are summarized below. In any case, the golden rule is: if you modify a source file, try to follow any conventions you can detect in the file or other similar files.
C/C++ guide[edit]
- See C++ style guide. For C, you should follow all C++ rules that can apply.
Octave guide[edit]
- See Octave style guide.
Help text style[edit]
Fortran guide[edit]
If you modify a Fortran file, you should stay within Fortran 77 with
common extensions like END DO. Currently, we want ensure that
it is possible to compile all sources with the gfortran compiler, without
special flags if possible. This usually means that non-legacy compilers
also accept the sources.
M4 guide[edit]
The M4 macro language is mainly used for Autoconf configuration files. You should follow normal M4 rules when contributing to these files. Some M4 files come from external source, namely the Autoconf archive.
Wiki guide[edit]
- Please try to fit a new page into the already existing category tree.
- If you have to create a new category, choose the name and place wisely (try to stay close to Wikipedia's categorization scheme).
- Instead of creating a new page and redirect it to another for link aliases, choose piped links instead. See here for more infos about piped links.
- The one and only root category is Category:Contents. All other categories have to point to it (over one or more subcategories).
- Start a new page title with a capital letter, the rest is written in lower case (except for names, cities, etc.).