We strongly encourage contributions of code, bug fixes, new optimizations, new intrinsic functions, documentation updates, web page improvements, etc. for G95.
There are certain legal requirements and style issues which all contributions must meet.
All contributions must conform to the GNU Coding Standards. There are also some additional coding conventions for GCC; these include documentation and testsuite requirements as well as requirements on code formatting. Submissions which do not conform to the standards will be returned with a request to address any such problems.
Before we can accept code contributions from you, we need a copyright assignment form filled out and filed with the FSF.
See some documentation by the FSF for details and contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer that is taking care of your contributions) to obtain the relevant forms. It's a good idea to send assignments@gnu.org a copy of your request.
Small changes can be accepted without a copyright assignment form on file.
All patches must be thoroughly tested. Of course you will have to make sure that G95 and its runtime libraries still build with your changes. We also ask of you that you test any changes with the full test suite. We do not yet require testing on more than a single platform for most changes, but we do ask you to be careful to try and keep the code target independent.
You will of course have tested that your change does what you expected it to do: fix a bug, improve an optimization, add a new feature. If the test framework permits, you should automate these tests and add them to G95's test suite. You must also perform regression tests to ensure that your patch does not break anything else.
If your change is to code that is not specific to the GNU Fortran 95 front end, you must submit the changes to GCC.
Documentation changes do not require a make of the compiler and the
libraries, but you must perform make info and make
dvi and correct any errors. You should investigate complaints
about overfull or underfull hboxes from make dvi, as
these can be the only indication of serious markup problems, but do
not feel obliged to eliminate them all.
Please report web site problems on the mailing list.
Every patch must have several pieces of information before we can properly evaluate it:
We prefer context diffs against CVS, so use
"cvs update; cvs diff -c3p". Always update the
your local tree before testing and submitting your patch, with
"cvs up -d".
If you don't use CVS, please make and test your patch against the most recent sources available, e.g. against a daily snapshot.
Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts. In particular, changes to code formatting to conform to coding standards are best not mixed with substantive changes, because that makes it difficult to see what the real changes are. (In the case of a very large reorganization of code, it may make sense to separate changes even further to make it clearer what has changed; for example, by first sending structural changes that make subsequent changes easier but do not change G95's behavior, then new code, then the changes that actually make use of the new code and change G95's behavior.)
When you have all these pieces, bundle them up in a mail message and send it to the mailing list. All patches and related discussion should be sent to this mailing list. For further information on the G95 CVS repository, see the CVS page.