Howto:Submit patches: Difference between revisions

No edit summary
 
Line 1: Line 1:
=== Patch Guidlines ===
=== Patch Guidelines ===


Any invasive or non-trivial patches should preferably adhere to the following recommendations:
Any invasive or non-trivial patches should preferably adhere to the following recommendations:


Try to make your patch optionally minimally invasive:
* Search the [http://sourceforge.net/mailarchive/forum.php?forum_id=1919 flightgear-devel list archives] ([http://www.flightgear.org/mail.html old]) for any relevant discussion and then post to the flightgear-devel mailing list describing your idea and discussing the scope of effort required.


* provide compile time switches to generally enable or disable your modifications (i.e. using #ifdefs, autoconf and automake macros) That way, you will ensure that your patch can  be easily disabled (excluded from compilation while remaining in the source tree) if it should cause trouble while any issues are addressed
* Try to make your patch optionally minimally invasive:
* provide capabilities to enable or disable your code modifications at startup time or even at  runtime, using command line options or preferably the PropertyTree and some simple GUI dialog to enable developers and users to decide whether  they want to activate your code. That way, it can be ensured that your code doesn't interfere with any other FlightGear components. This will make potential bug tracking much easier.
** provide compile time switches to generally enable or disable your modifications (i.e. using #ifdefs, autoconf and automake macros) That way, you will ensure that your patch can  be easily disabled (excluded from compilation while remaining in the source tree) if it should cause trouble while any issues are addressed
** provide capabilities to enable or disable your code modifications at startup time or even at  runtime, using command line options or preferably the PropertyTree and some simple GUI dialog to enable developers and users to decide whether  they want to activate your code. That way, it can be ensured that your code doesn't interfere with any other FlightGear components. This will make potential bug tracking much easier.


Try to carefully document those passages in your source code that:
* Try to carefully document those passages in your source code that:
* are non-obvious
** are non-obvious
* are hackish or workarounds
** are hackish or workarounds
* use code where you yourself aren't entirely sure if you're doing the right thing
** use code where you yourself aren't entirely sure if you're doing the right thing
* are known to negatively interfere with other FlightGear code
** are known to negatively interfere with other FlightGear code
 
* Try to make sure that your code isn't platform-specific. Hence, it is generally a good idea to make any contributions as cross-platform capable as possible


=== Patch Format ===
=== Patch Format ===