1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
# Policy for OpenSSL Committers
## Who is a committer?
OpenSSL committers are contributors who have commit access to the OpenSSL
source code repository. Committers review and commit their own patches
as well as those of other contributors.
## How to become a committer?
Commit access is granted by a vote of the [OMC] typically on the
recommendation of the [OTC] (see the [OpenSSL Bylaws]).
We welcome contributors who become domain experts in some part of
the library (for example, low-level crypto) as well as generalists
who contribute to all areas of the codebase. All committers share
the responsibility for the overall health of the project: aside from
contributing quality features, committers are team players who fix bugs,
address open issues, review community contributions, and improve tests
and documentation. Committers are also shepherds of the OpenSSL community
and its code of conduct.
To become a committer, start by contributing code. Read our coding style,
and get to know our build and test system. Then, use the Github issue
tracker, and our mailing lists to find impactful ideas to work on.
## How to maintain committer status?
To maintain committer status, you must stay active in the project. Refer
to the OpenSSL Bylaws for details.
In the unlikely and unfortunate event that your actions conflict with
the project objectives or are otherwise disruptive, committer status
may also be revoked by the OMC.
## Approvals and code reviews
All submissions must be reviewed and approved by at least two committers,
one of whom must also be an OTC member. Neither of the reviewers can
be the author of the submission.
The sole exception to this is during the release process where the
author's review does count towards the two needed for the automated
release process and [NEWS] and [CHANGES] file updates.
In the case where two committers make a joint submission, they can review
each other's code but not their own. A third reviewer will be required.
An OMC member may apply a _hold: needs OMC decision_ label to a submission.
An OTC member may apply a _hold: needs OTC decision_ to a submission.
A _hold: needs OMC decision_ label may be removed by the member that put
in place the hold or by a decision of the OMC.
A _hold: needs OTC decision_ label may be removed by the member that put
in place the hold or by a decision of the OTC.
Approved submissions (outside of the automated release process and
NEWS and CHANGES file updates) shall only be applied after a 24-hour
delay from the approval. An exception to the delay exists for build and
test breakage fix approvals which should be flagged with the _severity:
urgent_ label.
Contributors without commit rights cannot formally approve patches but
are nevertheless welcome to comment on submissions and do technical
reviews. We always value another pair of eyes, and volunteering for
reviews counts favourably towards becoming a committer. As an author,
we ask that you address all comments, even if you already have the
necessary approvals.
If you have trouble finding consensus on a difficult review, reach out to
the OTC at `otc@openssl.org` (private, moderated) or the project
at `openssl-project@openssl.org` (public, moderated). On GitHub, you can
reach the OMC members with `@openssl/omc`, OTC members with `@openssl/otc`,
or committers with `@openssl/committers`.
## Commit workflow
We do code reviews on GitHub. The OpenSSL GitHub repository is a mirror,
so we do not merge on GitHub. When you become a committer, we'll send
you instructions to get commit access to the main repository. To have
handy links to review history, we record the reviewers and GitHub pull
request IDs in commit headers. We have some helper scripts in the tools
repo to add these headers automatically.
We don't use merge commits.
If at any point during development or review you discover a potential
security issue, we ask that you report it to `openssl-security@openssl.org`
and don't discuss it further in public. We review security issues
privately, however acceptance of a submission for a security issue does
not bypass the review process that applies to all submissions.
## CLAs
All authors, including committers, must have current [CLAs] on file.
Refer to the [Contributor Agreements] page for further details.
## Trivial submissions
A CLA is not required for trivial contributions (e.g. the fix of a
spelling mistake). All reviewers and the submission author need to
agree that a submission is trivial and the _cla: trivial_ label should
be applied to indicate this.
[Contributor Agreements]: https://www.openssl.org/policies/cla.html
[OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html
[OMC]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#omc
[OTC]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#otc
[CLAs]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#cla
[NEWS]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#news
[CHANGES]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#changes
[OpenSSL Bylaws]: https://github.com/openssl/general-policies/blob/master/policies/glossary.md#bylaws
|
