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
(Howto Create Patches)
m (moved Howto: Submit patches to Howto:Submit patches: Robot: Moved page)
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
=== Patch Guidelines ===
+
== 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:
  
* 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.
+
* Search the [http://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-devel 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.
 +
* If you have developed several different features, make sure '''not''' to provide one big patch for all of these changes, but instead several smaller ones for each individual feature (likewise, use separate threads on the mailing list as well), that way you will enable developers to easily and independently review/discuss your patches [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16986.html].
  
 
* 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, [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 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) or is any way platform specific.
** 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 (check out $FG_SRC/Main/options.cxx) or preferably the PropertyTree/SGPropertyListeners and some simple GUI dialog (check out $FG_ROOT/gui) 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 and the chances of your code remaining in the source tree are much better as well.
 
+
** if you intend to add new features that may benefit from proper documentation, make sure to also provide patches to the documentation files provided under $FG_SRC/mini-docs and $FG_ROOT/Docs
 +
** new command line switches should also be documented via options.xml
 
* 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 or unfinished
 
** 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
 +
** seem to affect overall runtime performance of FlightGear
  
 
* 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
 
* 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
  
* If you need to print output to the terminal, make sure to use the SG_LOG logging mechanism, using the appropriate log level. Use this command sparingly, as excessive logging information has negative impact on framerate, especially on some platforms. When committing a patch, make sure you have either removed or commented out any cout or cerr statements that you have used during private debugging sessions.
+
* If you need to print output to the terminal, make sure to use the SG_LOG logging mechanism, using the appropriate log level. Use this command sparingly, as excessive logging information has negative impact on framerate, especially on some platforms (you can however easily use switches to generally enable/disable output of debugging information). When committing a patch, make sure you have either removed or commented out any cout or cerr statements that you have used during private debugging sessions.
 
+
=== Patch Format ===
+
TODO:  unified diff vs. tarball (compressed archives)
+
 
+
=== Howto Create Patches ===
+
 
+
'''fg-submit script'''
+
 
+
As of March 2007, a bash script "fg-submit" is available that simplifies the preparation of patches that are to be submitted to the maintainers. It can be found in '/source/scripts/tools'.  It compares your changes to cvs, creates a diff file and an archive containing your changed files and the diff file. Run this script from within the CVS directory containing your changes.
+
 
+
Usage:
+
$ cd $FG_ROOT/Aircraft/foo
+
$ fg-submit
+
 
+
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)'''
+
== Howto create and share patches ==
 +
{{Main article|Merge request}}
  
(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
+
[[Category:Development]]

Latest revision as of 11:53, 6 May 2012

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.
  • If you have developed several different features, make sure not to provide one big patch for all of these changes, but instead several smaller ones for each individual feature (likewise, use separate threads on the mailing list as well), that way you will enable developers to easily and independently review/discuss your patches [1].
  • 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) or is any way platform specific.
    • provide capabilities to enable or disable your code modifications at startup time or even at runtime, using command line options (check out $FG_SRC/Main/options.cxx) or preferably the PropertyTree/SGPropertyListeners and some simple GUI dialog (check out $FG_ROOT/gui) 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 and the chances of your code remaining in the source tree are much better as well.
    • if you intend to add new features that may benefit from proper documentation, make sure to also provide patches to the documentation files provided under $FG_SRC/mini-docs and $FG_ROOT/Docs
    • new command line switches should also be documented via options.xml
  • Try to carefully document those passages in your source code that:
    • are non-obvious or unfinished
    • 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
    • seem to affect overall runtime performance of FlightGear
  • 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
  • If you need to print output to the terminal, make sure to use the SG_LOG logging mechanism, using the appropriate log level. Use this command sparingly, as excessive logging information has negative impact on framerate, especially on some platforms (you can however easily use switches to generally enable/disable output of debugging information). When committing a patch, make sure you have either removed or commented out any cout or cerr statements that you have used during private debugging sessions.

Howto create and share patches

1rightarrow.png See Merge request for the main article about this subject.