Contributing Patches

Let's assume that you have found a bug in your ]project-open[ installation that you have fixed yourself.  Or maybe you have added a new feature to ]project-open[ that your would like to share for future releases of ]project-open[.  Now you would like to contribute this patch, so that it will be included in future releases.

The Mechanics

Please create the patch using the following commands:

cd /packages/your_package/www/


cvs -z3 diff -u source_file.tcl > patch.diff

Then please go to our Source Forge Bug Tracker  page and create a new Bug Report with all the necessary context of the problem ("bug") that your patch solves.  Please add a description of the intended new behavior after the patch has been applied.   Then please include your patch in the bug description, either in plain text (short patches) or via upload (longer patches).

Intellectual Property Rights

By contributing the patch you agree that your code will become part of the ]project-open[ source code and will be issued under the same license as the original source code file.

The Decision Process

Due to the long release cycle of ]project-open[ it may take several weeks or months before the ]project-open[ core team will decide on whether or not to include the patch in the next release.  At that moment, the team will mark the patch as "closed" (if it has been included) or as "rejected" (if it hasn't been included in the product).

Please Follow the Original Formatting

Please follow the formatting and code style of the original source code file for your patch.  We (]project-open[ core team) use the Emacs "TCL-mode" formatting, plus tabs for SQL and HTML statements.

Generic vs. Specific Patches

The ]project-open[ source code has been designed to be very "configurable" in order to serve diverse companies involved in many distinct industries.  Our primary targets and most successful implementations so far have been consulting companies, translation agencies, advertising companies and internal IT departments.   For this reason, the ]project-open[ code needs to honor and allow the specific configurations of each possibly diverse system.  For example, there can be no English plain text in the code, instead you must conform the internal localization system so that ]project-open[ can be localized easily to all global languages.  When deciding whether or not to accept a particular patch the ]project-open[ core team has several areas of concern, such as if the patch is suitable for different business sectors or solely targeted towards the interests of one industry and if all of these sectors will benefit from the inclusion of this patch into ]project-open[.

So please don't be disappointed if the ]project-open[ replies negatively because they have decided that your patch is too specific.