openbmc/docs/CONTRIBUTING.md

4 guidelines for contributing to an OpenBMC repository which are hosted in the
28 The BMC's interfaces to the external world are typically through a separate
31 These separate projects are then compiled into the final system by the overall
53 a look at the issues tagged with 'bitesize'. These are fixes or enhancements
54 that don't require extensive knowledge of the OpenBMC codebase, and are easier
65 you are interested in a particular repository - for example, "bmcweb" - type
74 upstream project. Otherwise, conventions are chosen based on the language.
100 E133, E226, E241, E242, E704, W503, and W504. These rules are ignored because
101 they are not unanimously accepted and PEP 8 does not enforce them. It is at the
148 If you are making a nontrivial change, you should plan how to introduce it to
151 If you are planning a new function, you should get agreement that your change
184 Often, creating small commits this way results in many commits that are
186 push commits which are based on your change still in review. However, when
189 that topics that are not related to each other semantically are also not related
190 to each other in Git until they are merged into master.
202 `git commit --amend`, for which there are many guides online. As mentioned in
209 should be clearly written - even more so than production code, unit tests are
222 - Concisely, _what_ change are you making? e.g. "libpldm: Add APIs to enable
224 - Comprehensively, _why_ are you making that change? In some cases, like a small
229 Try to include the component you are changing at the front of your subject line;
231 are modifying. e.g. "apphandler: refactor foo to new API"
237 Exceptions to this are allowed in the form of links, which can be represented in
259 separately, even if they are submitted together (an exception is when commits to
277 The guidelines in the Linux kernel are very useful:
295 Most repositories are supported by the Gerrit server, the current list can be
329 are:
352 file that lists required reviewers who are subject matter experts. Those
356 You are expected to respond to all comments. And remember to use the "reply"
363 Each repository is governed by a small group of maintainers who are leaders with
364 expertise in their area. They are responsible for reviewing changes and
385 - D-Bus interfaces are defined in the `phosphor-dbus-interfaces` repository at:
393 There are numerous resources available elsewhere, but a few items that are
417 - Systemd services should be contained within the OpenBMC repository they are
421   required service are started
436 Contributors who are used to code reviews by their team internal to their own
437 company, or who are not used to code reviews at all, are sometimes surprised by
450 The maintainers' job is to ensure that incoming patches are as correct and easy
481         are public and that a record of the contribution (including all