| ||
|
Contributing to the GCJ Project
| Project Ideas |
|---|
We've started maintaining a list of useful projects.
| Coding Standards |
|---|
All contributions must conform to the GNU Coding Standards. Submissions which do not conform to the standards will be returned with a request to reformat the changes.
Note that the GNU Coding Standards do not actually cover Java programming style. libgcj largely uses the obvious extrapolation from the GNU C style, but there are some differences. These aren't yet written down, but we'll make them available shortly.
| Copyright Assignment |
|---|
Before we can accept code contributions from you, we need a copyright assignment form filled out.
- If you've developed some addition or patch to libgcj that you would like to contribute, you should fill out a copyright assignment form and send it in to us. We are unable to use code from you until this is on-file.
- Small changes can be accepted without a copyright assignment form on file.
| Submitting Patches |
|---|
Every patch must have several pieces of information before we can properly evaluate it.
- A description of the bug and how your patch fixes this bug. For new features a description of the feature and your implementation.
- A ChangeLog entry as plaintext; see the various ChangeLog files
for format and content.
Note that, unlike some other projects, we do require ChangeLogs also for documentation (i.e., .texi files). - The patch itself. If you are accessing the CVS repository at Red Hat, use "cvs update; cvs diff -c3p"; else, use "diff -c3p OLD NEW" or "diff -up OLD NEW". If your version of diff does not support these options, then get the latest version of GNU diff.
Send patches to the patch mailing list. This list is archived.
| Checkins and Gnats |
|---|
If you have direct checkin access for libgcj, please make sure that your checkins follow the standard checkin rules.
First, always make ChangeLog entries. This is not negotiable; a checkin without a ChangeLog entry will be reverted. If the checkin fixes a bug in Gnats, note this in the entry.
The commit message given to cvs should be the ChangeLog entry. If you wrote the entry (your name is at the top), then don't include the header. If someone else wrote the entry, do include the header.
After checking in a fix which fixes a PR, put the PR into ``feedback'' mode. This will send email to the bug's originator. In the change message ask them to try the fix and report back.
Once the originator reports back, or after some suitable amount of time (less time if you are absolutely sure, beyond any shadow of a doubt, that the bug has been fixed) close the PR.
Contributing test cases
We're accepting test case patches.