libidn: Contributing

1 
1 1.9 Contributing
1 ================
1 
1 If you want to submit a patch for inclusion – from solve a typo you
1 discovered, up to adding support for a new feature – you should submit
1 it as a bug report (⇒Bug Reports).  There are some things that
1 you can do to increase the chances for it to be included in the official
1 package.
1 
1    Unless your patch is very small (say, under 10 lines) we require that
1 you assign the copyright of your work to the Free Software Foundation.
1 This is to protect the freedom of the project.  If you have not already
1 signed papers, we will send you the necessary information when you
1 submit your contribution.
1 
1    For contributions that doesn’t consist of actual programming code,
1 the only guidelines are common sense.  Use it.
1 
1    For code contributions, a number of style guides will help you:
1 
11    • Coding Style.  Follow the GNU Standards document (⇒GNU Coding
      Standards (standards)top.).
1 
1      If you normally code using another coding standard, there is no
11      problem, but you should use ‘indent’ to reformat the code (⇒
      GNU Indent (indent)top.) before submitting your work.
1 
1    • Use the unified diff format ‘diff -u’.
1 
1    • Return errors.  No reason whatsoever should abort the execution of
1      the library.  Even memory allocation errors, e.g.  when malloc
1      return NULL, should work although result in an error code.
1 
1    • Design with thread safety in mind.  Don’t use global variables and
1      the like.
1 
1    • Avoid using the C math library.  It causes problems for embedded
1      implementations, and in most situations it is very easy to avoid
1      using it.
1 
1    • Document your functions.  Use comments before each function
1      headers, that, if properly formatted, are extracted into GTK-DOC
1      web pages.  Don’t forget to update the Texinfo manual as well.
1 
1    • Supply a ChangeLog and NEWS entries, where appropriate.
1