@@ -9,31 +9,45 @@ Development is done on GitHub in the [openssl/openssl] repository.
9
9
10
10
[ openssl/openssl ] : < https://github.com/openssl/openssl >
11
11
12
- To request new features or report bugs, please open an issue on GitHub
12
+ To request new a feature, ask a question, or report a bug,
13
+ please open an [ issue on GitHub] ( https://github.com/openssl/openssl/issues ) .
13
14
14
- To submit a patch, please open a pull request on GitHub. If you are thinking
15
- of making a large contribution, open an issue for it before starting work,
16
- to get comments from the community. Someone may be already working on
17
- the same thing or there may be reasons why that feature isn't implemented.
15
+ To submit a patch or implement a new feature, please open a
16
+ [ pull request on GitHub] ( https://github.com/openssl/openssl/pulls ) .
17
+ If you are thinking of making a large contribution,
18
+ open an issue for it before starting work, to get comments from the community.
19
+ Someone may be already working on the same thing,
20
+ or there may be special reasons why a feature is not implemented.
18
21
19
22
To make it easier to review and accept your pull request, please follow these
20
23
guidelines:
21
24
22
25
1 . Anything other than a trivial contribution requires a [ Contributor
23
26
License Agreement] (CLA), giving us permission to use your code.
24
- If your contribution is too small to require a CLA (e.g. fixing a spelling
25
- mistake), place the text "` CLA: trivial ` " on a line by itself separated by
26
- an empty line from the rest of the commit message. It is not sufficient to
27
- only place the text in the GitHub pull request description.
27
+ If your contribution is too small to require a CLA (e.g., fixing a spelling
28
+ mistake), then place the text "` CLA: trivial ` " on a line by itself below
29
+ the rest of your commit message separated by an empty line, like this:
30
+
31
+ ```
32
+ One-line summary of trivial change
33
+
34
+ Optional main body of commit message. It might contain a sentence
35
+ or two explaining the trivial change.
36
+
37
+ CLA: trivial
38
+ ```
39
+
40
+ It is not sufficient to only place the text "`CLA: trivial`" in the GitHub
41
+ pull request description.
28
42
29
43
[Contributor License Agreement]: <https://www.openssl.org/policies/cla.html>
30
44
31
45
To amend a missing "`CLA: trivial`" line after submission, do the following:
32
46
33
47
```
34
48
git commit --amend
35
- [ add the line, save and quit the editor]
36
- git push -f
49
+ # add the line, save and quit the editor
50
+ git push -f [<repository> [<branch>]]
37
51
```
38
52
39
53
2. All source files should start with the following text (with
@@ -53,22 +67,24 @@ guidelines:
53
67
often. We do not accept merge commits, you will have to remove them
54
68
(usually by rebasing) before it will be acceptable.
55
69
56
- 4. Patches should follow our [coding style] and compile without warnings.
57
- Where `gcc` or `clang` is available you should use the
70
+ 4. Code provided should follow our [coding style] and compile without warnings.
71
+ There is a [Perl tool](util/check-format.pl) that helps
72
+ finding code formatting mistakes and other coding style nits.
73
+ Where `gcc` or `clang` is available, you should use the
58
74
`--strict-warnings` `Configure` option. OpenSSL compiles on many varied
59
- platforms: try to ensure you only use portable features. Clean builds via
60
- GitHub Actions and AppVeyor are required, and they are started automatically
61
- whenever a PR is created or updated.
75
+ platforms: try to ensure you only use portable features.
76
+ Clean builds via GitHub Actions are required. They are started automatically
77
+ whenever a PR is created or updated by committers .
62
78
63
79
[coding style]: https://www.openssl.org/policies/technical/coding-style.html
64
80
65
- 5. When at all possible, patches should include tests. These can
81
+ 5. When at all possible, code contributions should include tests. These can
66
82
either be added to an existing test, or completely new. Please see
67
83
[test/README.md](test/README.md) for information on the test framework.
68
84
69
85
6. New features or changed functionality must include
70
- documentation. Please look at the " pod" files in doc/man[1357] for
71
- examples of our style. Run " make doc-nits" to make sure that your
86
+ documentation. Please look at the `. pod` files in ` doc/man[1357]` for
87
+ examples of our style. Run ` make doc-nits` to make sure that your
72
88
documentation changes are clean.
73
89
74
90
7. For user visible changes (API changes, behaviour changes, ...),
@@ -78,7 +94,7 @@ guidelines:
78
94
Have a look through existing entries for inspiration.
79
95
Please note that this is NOT simply a copy of git-log one-liners.
80
96
Also note that security fixes get an entry in [CHANGES.md](CHANGES.md).
81
- This file helps users get more in depth information of what comes
97
+ This file helps users get more in- depth information of what comes
82
98
with a specific release without having to sift through the higher
83
99
noise ratio in git-log.
84
100
0 commit comments