Process incoming NewSessionTicket messages on the client side
[openssl.git] / CONTRIBUTING
1 HOW TO CONTRIBUTE PATCHES TO OpenSSL
2 ------------------------------------
3
4 (Please visit https://www.openssl.org/community/getting-started.html for
5 other ideas about how to contribute.)
6
7 Development is coordinated on the openssl-dev mailing list (see the
8 above link or https://mta.openssl.org for information on subscribing).
9 If you are unsure as to whether a feature will be useful for the general
10 OpenSSL community you might want to discuss it on the openssl-dev mailing
11 list first.  Someone may be already working on the same thing or there
12 may be a good reason as to why that feature isn't implemented.
13
14 To submit a patch, make a pull request on GitHub.  If you think the patch
15 could use feedback from the community, please start a thread on openssl-dev
16 to discuss it.
17
18 Having addressed the following items before the PR will help make the
19 acceptance and review process faster:
20
21     1. Anything other than trivial contributions will require a contributor
22     licensing agreement, giving us permission to use your code. See
23     https://www.openssl.org/policies/cla.html for details.
24
25     2.  All source files should start with the following text (with
26     appropriate comment characters at the start of each line and the
27     year(s) updated):
28
29         Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
30
31         Licensed under the OpenSSL license (the "License").  You may not use
32         this file except in compliance with the License.  You can obtain a copy
33         in the file LICENSE in the source distribution or at
34         https://www.openssl.org/source/license.html
35
36     3.  Patches should be as current as possible; expect to have to rebase
37     often. We do not accept merge commits; You will be asked to remove
38     them before a patch is considered acceptable.
39
40     4.  Patches should follow our coding style (see
41     https://www.openssl.org/policies/codingstyle.html) and compile without
42     warnings. Where gcc or clang is available you should use the
43     --strict-warnings Configure option.  OpenSSL compiles on many varied
44     platforms: try to ensure you only use portable features.
45     Clean builds via Travis and AppVeyor are expected, and done whenever
46     a PR is created or updated.
47
48     5.  When at all possible, patches should include tests. These can
49     either be added to an existing test, or completely new.  Please see
50     test/README for information on the test framework.
51
52     6.  New features or changed functionality must include
53     documentation. Please look at the "pod" files in doc/man[1357]
54     for examples of our style.