Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Howto:Submit patches"

From FlightGear wiki
Jump to: navigation, search
(Patch Guidlines)
Line 6: Line 6:
  
 
* Try to make your patch optionally minimally invasive:
 
* Try to make your patch optionally minimally invasive:
** 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 compile time switches to generally enable or disable your modifications (i.e. using #ifdefs, [http://sources.redhat.com/autobook/ 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. This applies in particular if your patch introduces any extra dependencies (i.e. libraries).
 
** 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 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.
  

Revision as of 08:21, 18 June 2006

Patch Guidelines

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

  • Search the flightgear-devel list archives (old) for any relevant discussion and then post to the flightgear-devel mailing list describing your idea and discussing the scope of effort required.
  • Try to make your patch optionally minimally invasive:
    • 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. This applies in particular if your patch introduces any extra dependencies (i.e. libraries).
    • 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:
    • are non-obvious
    • are hackish or workarounds
    • 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
  • 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

TODO: unified diff vs. tarball (compressed archives)

Howto Create Patches

TODO: links to diff/patch tutorials link to diff/patch utilities for various platforms

recommended: KDiff3 (QT based cross platform, GUI frontend to GNU diff/patch) http://kdiff3.sourceforge.net

Where to Send Patches

Developers with CVS access :

FlightGear developer mailing list(subscription required)

(any non-trivial or larger patches should preferably not be sent by email, but rather made available by putting a tarball of your patch on some free webspace, so that people can simply download your patch if they are interested