doc/cha-support.texi

   1 @node Support
   2 @appendix Support
   3
   4 @menu
   5 * Getting help::
   6 * Commercial Support::
   7 * Bug Reports::
   8 * Contributing::
   9 @end menu
  10
  11 @node Getting help
  12 @section Getting Help
  13
  14 A mailing list where users may help each other exists, and you can
  15 reach it by sending e-mail to @email{help-gnutls@@gnu.org}.  Archives
  16 of the mailing list discussions, and an interface to manage
  17 subscriptions, is available through the World Wide Web at
  18 @url{http://lists.gnu.org/mailman/listinfo/help-gnutls}.
  19
  20 A mailing list for developers are also available, see
  21 @url{http://www.gnu.org/software/gnutls/lists.html}.
  22 Bug reports should be sent to @email{bug-gnutls@@gnu.org}, see
  23 @ref{Bug Reports}.
  24
  25 @node Commercial Support
  26 @section Commercial Support
  27
  28 Commercial support is available for users of GnuTLS.  The kind of
  29 support that can be purchased may include:
  30
  31 @itemize
  32
  33 @item Implement new features.
  34 Such as a new TLS extension.
  35
  36 @item Port GnuTLS to new platforms.
  37 This could include porting to an embedded platforms that may need
  38 memory or size optimization.
  39
  40 @item Integrating TLS as a security environment in your existing project.
  41
  42 @item System design of components related to TLS.
  43
  44 @end itemize
  45
  46 If you are interested, please write to:
  47
  48 @verbatim
  49 Simon Josefsson Datakonsult
  50 Hagagatan 24
  51 113 47 Stockholm
  52 Sweden
  53
  54 E-mail: simon@josefsson.org
  55 @end verbatim
  56
  57 If your company provides support related to GnuTLS and would like to
  58 be mentioned here, contact the authors.
  59
  60
  61 @node Bug Reports
  62 @section Bug Reports
  63 @cindex reporting bugs
  64
  65 If you think you have found a bug in GnuTLS, please investigate it and
  66 report it.
  67
  68 @itemize @bullet
  69
  70 @item Please make sure that the bug is really in GnuTLS, and
  71 preferably also check that it hasn't already been fixed in the latest
  72 version.
  73
  74 @item You have to send us a test case that makes it possible for us to
  75 reproduce the bug.
  76
  77 @item You also have to explain what is wrong; if you get a crash, or
  78 if the results printed are not good and in that case, in what way.
  79 Make sure that the bug report includes all information you would need
  80 to fix this kind of bug for someone else.
  81
  82 @end itemize
  83
  84 Please make an effort to produce a self-contained report, with
  85 something definite that can be tested or debugged.  Vague queries or
  86 piecemeal messages are difficult to act on and don't help the
  87 development effort.
  88
  89 If your bug report is good, we will do our best to help you to get a
  90 corrected version of the software; if the bug report is poor, we won't
  91 do anything about it (apart from asking you to send better bug
  92 reports).
  93
  94 If you think something in this manual is unclear, or downright
  95 incorrect, or if the language needs to be improved, please also send a
  96 note.
  97
  98 Send your bug report to:
  99
 100 @center @samp{bug-gnutls@@gnu.org}
 101
 102 @node Contributing
 103 @section Contributing
 104 @cindex contributing
 105 @cindex hacking
 106
 107 If you want to submit a patch for inclusion -- from solving a typo you
 108 discovered, up to adding support for a new feature -- you should
 109 submit it as a bug report, using the process in @ref{Bug Reports}.  There are some
 110 things that you can do to increase the chances for it to be included
 111 in the official package.
 112
 113 Unless your patch is very small (say, under 10 lines) we require that
 114 you assign the copyright of your work to the Free Software Foundation.
 115 This is to protect the freedom of the project.  If you have not
 116 already signed papers, we will send you the necessary information when
 117 you submit your contribution.
 118
 119 For contributions that doesn't consist of actual programming code, the
 120 only guidelines are common sense.
 121 For code contributions, a number of style guides will help you:
 122
 123 @itemize @bullet
 124
 125 @item Coding Style.
 126 Follow the GNU Standards document.
 127 @c (@pxref{top, GNU Coding Standards,,standards}).
 128
 129 If you normally code using another coding standard, there is no
 130 problem, but you should use @samp{indent} to reformat the code
 131 @c (@pxref{top, GNU Indent,, indent})
 132 before submitting your work.
 133
 134 @item Use the unified diff format @samp{diff -u}.
 135
 136 @item Return errors.
 137 No reason whatsoever should abort the execution of the library.  Even
 138 memory allocation errors, e.g. when malloc return NULL, should work
 139 although result in an error code.
 140
 141 @item Design with thread safety in mind.
 142 Don't use global variables.  Don't even write to per-handle global
 143 variables unless the documented behaviour of the function you write is
 144 to write to the per-handle global variable.
 145
 146 @item Avoid using the C math library.
 147 It causes problems for embedded implementations, and in most
 148 situations it is very easy to avoid using it.
 149
 150 @item Document your functions.
 151 Use comments before each function headers, that, if properly
 152 formatted, are extracted into Texinfo manuals and GTK-DOC web pages.
 153
 154 @item Supply a ChangeLog and NEWS entries, where appropriate.
 155
 156 @end itemize
 157