1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768 |
- HOW TO CONTRIBUTE TO PATCHES OpenSSL
- ------------------------------------
- (Please visit https://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 http://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.
- The best way to submit a patch is to make a pull request on GitHub.
- (It is not necessary to send mail to rt@openssl.org to open a ticket!)
- If you think the patch could use feedback from the community, please
- start a thread on openssl-dev.
- You can also submit patches by sending it as mail to rt@opensslorg.
- Please include the word "PATCH" and an explanation of what the patch
- does in the subject line. If you do this, our preferred format is "git
- format-patch" output. For example to provide a patch file containing the
- last commit in your local git repository use the following command:
- % git format-patch --stdout HEAD^ >mydiffs.patch
- Another method of creating an acceptable patch file without using git is as
- follows:
- % cd openssl-work
- ...make your changes...
- % ./Configure dist; make clean
- % cd ..
- % diff -ur openssl-orig openssl-work >mydiffs.patch
- Note that pull requests are generally easier for the team, and community, to
- work with. Pull requests benefit from all of the standard GitHub features,
- including code review tools, simpler integration, and CI build support.
- No matter how a patch is submitted, the following items 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://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. When using GitHub, please
- expect to have to rebase and update often.
- 3. Patches should follow our coding style (see
- https://www.openssl.org/policies/codingstyle.html) and compile without
- warnings using the --strict-warnings flag. OpenSSL compiles on many
- varied platforms: try to ensure you only use portable features.
- 4. 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.
|