forked from ni/meta-openembedded
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
CONTRIBUTING: remove styleguide info
The styleguide information from the nilrt.git CONTRIBUTING document has been copied into the meta-nilrt.git:docs/styleguide.md doc, in meta-nilrt [openembedded#447](ni/meta-nilrt#447). Remove it from the CONTRIBUTING doc. Signed-off-by: Alex Stewart <[email protected]>
- Loading branch information
Showing
1 changed file
with
0 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,36 +38,6 @@ Github PRs should be preferred in all cases. If it is not possible for you to us | |
| **Security concerns** are best filed with the [NI security team](https://www.ni.com/en-us/support/security.html) via the group email: <[[email protected]](mailto:[email protected])>. | ||
|
|
||
|
|
||
| ## NI OE Styleguide | ||
|
|
||
| ### Where to make recipe changes? | ||
|
|
||
| OE recipe metadata is distributed across bitbake layers within the project, and it is generally important to the health of the distribution that recipe changes are made in the appropriate layers. | ||
|
|
||
| If your recipe changes are appropriate for the OpenEmbedded community as a whole, they should be submitted to the appropriate community-layer upstream first. Once accepted by upstream, they should be cherry-picked back into the NI-owned fork of the layer. | ||
|
|
||
| If your recipe changes are specific to NI LinuxRT, they should be made in the `meta-nilrt` layer. | ||
|
|
||
| Keep in mind that it might be most-correct to split your patchset changes across layers, if part of the changes are OE-generic and part are NILRT-specific. | ||
|
|
||
| ### .patch Files | ||
|
|
||
| [Example of a good .patch file commit.](https://github.com/ni/meta-nilrt/pull/50/commits/73b046c57d73e188a3bf4adbf0965aa9312ebe08) | ||
|
|
||
| `.patch` files should include the original author's commit message and meta information at their top. Information about the OE context (like why the `.patch` file is needed for the recipe) should be added after the original author's commit. | ||
|
|
||
| At a minimum, you should add an additional message trailer declaring the upstream status of the .patch file at the time of your OE commit. These status lines are crucial to helping the project maintainers properly upgrade and rebase recipes. Common status lines are: | ||
|
|
||
| * `Upstream-Status: Inappropriate [$rationale]` ([ex](https://github.com/ni/meta-nilrt/blob/nilrt/master/sumo/recipes-support/curl/curl/0005-Add-nicurl-wrapper-functions.patch)) For when the `.patch` change is specific to NI LinuxRT and would not be desired (or has been rejected) by upstream. | ||
| * `Upstream-Status: Not Submitted [$rationale]` ([ex](https://github.com/ni/meta-nilrt/blob/nilrt/master/sumo/recipes-gnome/florence/files/0004-Add-option-for-automatic-bring-to-top.patch)) For when the `.patch` file is being included in NILRT before being submitted to its upstream project. This should only occur if the `.patch` is needed for an immediate NILRT release and there is no time to get it reviewed upstream beforehand. Or if - as in the case of the example - the upstream mailing list is dead. | ||
| * `Upstream-Status: Submitted [$upstream_mailing_list_link]` ([ex](https://github.com/ni/meta-nilrt/blob/1e6453ebca8735de96eaaf3bc931d22998c8dfb3/recipes-support/curl/curl/0014-Fixup-lib1529-test.patch)) For when the `.patch` has been submitted to the upstream project's mailing list, but needs to be pulled into NILRT prior to final upstream approval. | ||
| * `Upstream-Status: Accepted [$upstream_mailing_list_link]` ([ex](https://github.com/ni/meta-nilrt/blob/904bd00bf24d8fe61d3a13b8ece368c9741a73fc/recipes-devtools/opkg/files/0002-libopkg-clear-curl-properties-on-download-error-to-p.patch#L36)) For when the `.patch` has been approved and pulled by the upstream project. | ||
|
|
||
|
|
||
| #### .patch file names | ||
|
|
||
| When bitbake applies `.patch` files to a recipe, it copies all `.patch` files into the recipe's workspace, then applies them in alphanumeric-order. In your PR, be mindful of how your `.patch` file is ordered versus the other files in the recipe. Keep in mind that some `.patch` files might come from other layers. | ||
|
|
||
| ## Developer Certificate of Origin (DCO) | ||
|
|
||
| Developer's Certificate of Origin 1.1 | ||
|
|
||