openbmc/docs/meta-layer-guidelines.md

1 # OpenBMC meta layer guidelines
10 ## Meta layers should not patch projects that exist within the openBMC tree
40 changes that OpenBMC stacks against Yocto recipes, the more unmaintainable it
42 the Yocto community is as responsive (sometimes much faster) than the OpenBMC
49 cherry-pick the commit into the OpenBMC tree, with a pointer to the review in
59 There are some OpenBMC projects that are utilized outside of OpenBMC. As such,
60 there are configuration items that are not intended to be used in OpenBMC, or
78 OpenBMC is an open source project, and is intended to be built from source, with
91 Without this guideline, a loophole is present that allows OpenBMC developers to
93 they control, but which OpenBMC has no input on the content of. This splits the
95 processes within OpenBMC like bug tracking and continuous integration from
101 for use on OpenBMC, then push a design doc, and push the code to openbmc gerrit
102 under the openbmc/openbmc repository where it can be reviewed, along with an
106 community through the mailing list or discord whether or not the OpenBMC
109 ## Meta layers should not point to OpenBMC specific repositories outside of
111 https://github.com/openbmc
113 **What defines an OpenBMC specific repository?**
115 Generally an OpenBMC specific repository is something that does any of the
118 - Relies on or implements on OpenBMC defined Dbus interfaces.
119 - Is not designed with configurability to be used outside of OpenBMC
120 - Relies on OpenBMC specific layouts, configuration information to accomplish
125 OpenBMC as a codebase needs to remain buildable in the long term. Companies,
127 Keeping all long-term-supported code in the OpenBMC github ensures that the
129 OpenBMC-specific code outside of github limits the ability of the project to do
132 getting patches accepted when repositories are not within the OpenBMC github
139 the OpenBMC technical oversight committee process.