|
|
||
|
|
i
Contributing to the Source-NavigatorTM IDE
Source-Navigator is a collaborative project and one which wants to encourage new development. You may wish to fix Source-Navigator bugs, improve testing, port Source-Navigator to a new platform, update documentation, add new features, and the like. To help with this, there is some documentation available. In addition to the User Guide included in the distribution, the Source-Navigator web pages also contain much information.
You may also wish to submit patches so that they can be considered for inclusion in a future version of Source-Navigator. By submitting your patch, you agree to license your changes under the terms of the GPL. See the mailing lists page for info about where to send your patch.
If you don't feel up to hacking Source-Navigator, there are still plenty of ways to help! You can answer questions on the mailing lists, write documentation, find bugs, create a Source-Navigator related website, contribute to the official Source-Navigator web site, or create a Source-Navigator related software package. We welcome all of the above. Feel free to ask for any info you need on the mailing list.
Finally, there are certain requirements and style issues which all contributors need to be aware of.
|
Coding Standards |
|---|
All contributions must conform to the Tcl/Tk Coding Standards (there is one set for C and one set for Tcl). Submissions which do not conform to the standards will be returned with a request to reformat the changes. Please note that some of the code, especially in the current release, is not to this standard. In the case where patches are submitted in code that does not conform to the coding standards, please try to use the style the code is currently written in. The maintainers will try to use common sense when asking for reformatting.
|
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. A reference to a test suite failure (once we have a test suite in place! An opportunity for contribution!) is very helpful. For new features a description of the feature and your implementation.
- A ChangeLog entry as plaintext (separate from the patch); see the various ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation (i.e., .html files).
- The patch itself. Use "diff -up OLD NEW" with GNU diff. If you are going to submit more than one patch we suggest you check the code out of the CVS and create your patches via "cvs diff -u".
We accept patches as plain text (preferred for the code itself), MIME attachments (preferred for the web pages), or as uuencoded gzipped text. See the mailing lists page for info about where to send your patch.
|
Supplemental Information |
|---|
- Please try to run the relevant test suite before and after committing a patch If the contributor doesn't do it then the maintainer will. A contributor might include before/after test results in their contribution. This assumes, of course, that there is a test suite for the feature or patch. While we will not require development of a test harness before accepting patches, once one is in place, we will request tests for any new features.
- For bug fixes, please try to include a way of demonstrating that the patch actually fixes something. The best way of doing this is to ensure that the test suite contains one or more test cases that fail without the fix but pass with the fix.
- People are encouraged to submit patches that extend the test suite.
- Please read your patch before submitting it. A patch containing several unrelated changes or arbitrary reformats will be returned with a request to reformat / split it.
- If any configure files, such as acinclude.m4, configure.in, Makefile.am, etc. files are including, the files that they generate should not be included. The maintainer will regenerate those files.