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