Skip to content

CONTRIBUTING: remove styleguide info #168

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
amstewart merged 1 commit into from
Aug 23, 2022
Merged

CONTRIBUTING: remove styleguide info #168

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 0 additions & 30 deletions docs/CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down