CONTRIBUTING.txt 2.5 KB

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