[thirdparty/openssl.git] / CONTRIBUTING

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