xref: /openbmc/docs/maintainer-workflow.md (revision ef31648c)
1# OpenBMC Maintainer/CLA Workflow
2OpenBMC contributors are required to execute an OpenBMC CLA (Contributor
3License Agreement) before their contributions can be accepted.  This page is a
4checklist for sub-project maintainers to follow before approving patches.
5
6* Manually verify the contributor has signed the ICLA (individual) or is
7listed on an existing CCLA (corporate).
8	* Executed CLAs can be found [in the CLA repository]
9	(https://drive.google.com/drive/folders/1Ooi0RdTcaOWF1DWFJUAJDdN7tRKde7Nl).
10	* If you were not added to the appropriate CLA repository ACL send an
11email to openbmc@lists.ozlabs.org with a request to be added.
12	* If a CLA for the contributor is found, accept the patch(1).
13* If a CLA is not found, request that the contributor execute one and send it
14to openbmc@lists.ozlabs.org.
15	* Do not accept the patch(1) until a signed CLA (individual _or_
16corporate) has been uploaded to the CLA repository.
17	* The CCLA form can be found [here]
18	(https://github.com/openbmc/openbmc/files/1860741/OpenBMC.CCLA.pdf).
19	* The ICLA form can be found [here]
20	(https://github.com/openbmc/openbmc/files/1860742/OpenBMC.ICLA.pdf).
21
22An executed OpenBMC CLA is _not_ required to accept contributions to
23OpenBMC forks of upstream projects, like the Linux kernel or U-Boot.
24
25Review the maintainers' responsibilities in the [contributing
26guidelines](./CONTRIBUTING.md).  Maintainers are ultimately
27responsible for sorting out open source license issues, issues with
28using code copied from the web, and maintaining the quality of the
29code.
30
31Repository maintainers ought to have the following traits as
32recognized by a consensus of their peers:
33 - responsible: have a continuing desire to ensure only high-quality
34   code goes into the repo
35 - leadership: foster open-source aware practices such as [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software)
36 - expertise: typically demonstrated by significant contributions to
37   the code or code reviews
38
39(1) The semantics of accepting a patch depend on the sub-project contribution
40process.
41
42* Github pull requests - Merging the pull request.
43* Gerrit - +2.
44* email - Merging the patch.
45
46Ensure that accepted changes actually merge into OpenBMC repositories.
47