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