[thirdparty/openssl.git] / CONTRIBUTING

HOW TO CONTRIBUTE PATCHES TO OpenSSL
------------------------------------

(Please visit https://www.openssl.org/community/getting-started.html for
other ideas about how to contribute.)

Development is coordinated on the openssl-dev mailing list (see the
above link or https://mta.openssl.org for information on subscribing).
If you are unsure as to whether a feature will be useful for the general
OpenSSL community you might want to discuss it on the openssl-dev mailing
list first.  Someone may be already working on the same thing or there
may be a good reason as to why that feature isn't implemented.

To submit a patch, make a pull request on GitHub.  If you think the patch
could use feedback from the community, please start a thread on openssl-dev
to discuss it.

Having addressed the following items before the PR will help make the
acceptance and review process faster:

    1. Anything other than trivial contributions will require a contributor
    licensing agreement, giving us permission to use your code. See
    https://www.openssl.org/policies/cla.html for details.

    2.  All source files should start with the following text (with
    appropriate comment characters at the start of each line and the
    year(s) updated):

        Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.

        Licensed under the OpenSSL license (the "License").  You may not use
        this file except in compliance with the License.  You can obtain a copy
        in the file LICENSE in the source distribution or at
        https://www.openssl.org/source/license.html

    3.  Patches should be as current as possible; expect to have to rebase
    often. We do not accept merge commits; You will be asked to remove
    them before a patch is considered acceptable.

    4.  Patches should follow our coding style (see
    https://www.openssl.org/policies/codingstyle.html) and compile without
    warnings. Where gcc or clang is available you should use the
    --strict-warnings Configure option.  OpenSSL compiles on many varied
    platforms: try to ensure you only use portable features.
    Clean builds via Travis and AppVeyor are expected, and done whenever
    a PR is created or updated.

    5.  When at all possible, patches should include tests. These can
    either be added to an existing test, or completely new.  Please see
    test/README for information on the test framework.

    6.  New features or changed functionality must include
    documentation. Please look at the "pod" files in doc/man[1357]
    for examples of our style.
Commit	Line	Data
e4d94269	1	HOW TO CONTRIBUTE PATCHES TO OpenSSL
f2b9c257	2	------------------------------------
eb05f173	3
75737d4f	4	(Please visit https://www.openssl.org/community/getting-started.html for
f2b9c257	5	other ideas about how to contribute.)
eb05f173	6
f2b9c257	7	Development is coordinated on the openssl-dev mailing list (see the
75737d4f	8	above link or https://mta.openssl.org for information on subscribing).
eb05f173	9	If you are unsure as to whether a feature will be useful for the general
f2b9c257 RS	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.
eb05f173	13
7954dced RS	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.
c5eed277	17
7954dced RS	18	Having addressed the following items before the PR will help make the
7954dced RS	19	acceptance and review process faster:
f2b9c257 RS	20
	21	1. Anything other than trivial contributions will require a contributor
	22	licensing agreement, giving us permission to use your code. See
75737d4f	23	https://www.openssl.org/policies/cla.html for details.
f2b9c257 RS	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
7954dced RS	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.
f2b9c257	39
75737d4f	40	4. Patches should follow our coding style (see
f2b9c257	41	https://www.openssl.org/policies/codingstyle.html) and compile without
f430ba31	42	warnings. Where gcc or clang is available you should use the
75737d4f MC	43	--strict-warnings Configure option. OpenSSL compiles on many varied
75737d4f MC	44	platforms: try to ensure you only use portable features.
7954dced RS	45	Clean builds via Travis and AppVeyor are expected, and done whenever
7954dced RS	46	a PR is created or updated.
f2b9c257	47
7954dced RS	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.
49c2a00d	51
7954dced	52	6. New features or changed functionality must include
663ece0f BB	53	documentation. Please look at the "pod" files in doc/man[1357]
663ece0f BB	54	for examples of our style.