phosphor-host-ipmid/docs/contributing.md

4 to OpenBMC's IPMI stack. It does _not_ outline coding style; we follow the
5 [OpenBMC C++ style guide](https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions)
13 - Too large: "convert foo to new API; also fix CVE 1234 in bar"
14 - Too small: "move abc.h to top of include list" and "move xyz.h to bottom of
16 - Just right: "convert foo to new API" and "convert foo from tab to space"
21 possible, your commit should stand alone on top of master - "Fix whitespace in
24 related to each other in Git until they are merged into master.
28 gerrit. This means that each patch must be merged in order of that relationship.
36 send it again to Gerrit. This typically involves `git rebase --interactive` or
37 `git commit --amend`, for which there are many guides online. As mentioned in
44 should be clearly written - even moreso than production code, unit tests are
45 meant primarily to be read by humans - and should test both good and bad
47 [testing documentation](https://github.com/openbmc/phosphor-host-ipmid/blob/master/docs/testing.md)
54 - Concisely, _what_ change are you making? e.g. "docs: convert from US to UK
56 - Comprehensively, _why_ are you making that change? In some cases, like a small
59 - Concisely, _how_ did you test? This comes in the form of a "Tested:" footer in
61   typically consists of copy-pasted ipmitool requests and responses. When
62   possible, use the high-level ipmitool commands (e.g. "ipmitool sensor read
63   0x1"). In cases where that's not possible, or when testing edge or error
64   cases, it is acceptable to use "ipmitool raw" - but an explanation of your
72 Loosely, we try to follow the 50/72 rule for commit messages - that is, the
76 All commit messages must include a Signed-off-by line, which indicates that you
86 change to be merged. Submitters will need to manually add their reviewers in
96 partial-time capacity, may be in a timezone far removed from your own, and may
100 If you feel your patch has been missed entirely, of course it's alright to email
101 the maintainers (addresses available in MAINTAINERS file) - but a reasonable
109 to maintain as possible. Part of the nature of open source is attrition -
110 contributors can come and go easily - so maintainers tend not to put stock in
120 [Code of Conduct](https://github.com/openbmc/docs/blob/master/code-of-conduct.md)