Skip to content
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.

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

apps: migrate to SPDX identifier #2899

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

jerpelea
Copy link
Contributor

Summary

Most tools used for compliance and SBOM generation use SPDX identifiers This change brings us a step closer to an easy SBOM generation.

Impact

SBOM

Testing

CI

Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
@nuttxpr
Copy link

nuttxpr commented Dec 18, 2024

[Experimental Bot, please feedback here]

No, this PR description does not meet the NuttX requirements. While it attempts to follow the structure, it lacks crucial details. Here's why:

  • Summary: While it states the why, it's vague. What tools? What kind of SPDX identifiers? It completely omits what is changing, how the change works, and any related issue references. Example: "This change adds SPDX license identifiers to the source files within the core OS directory (e.g., sched/, drivers/). This will allow tools like [tool name] to generate a compliant SBOM. This addresses issue #[issue number]."

  • Impact: Simply stating "SBOM" isn't helpful. You need to address all impact points with "YES/NO" and descriptions where necessary. For example, "Impact on documentation: YES - The README will be updated to explain how to generate an SBOM." Even if the answer is "NO", state it explicitly.

  • Testing: "CI" isn't sufficient. List the specific build hosts and targets tested. Provide actual log snippets demonstrating the change's effect, not just "your testing logs here". Show the absence of SPDX identifiers before and their presence after the change. Example:

    • Build Host(s): Linux (Ubuntu 22.04), x86_64, GCC 11.2
    • Target(s): qemu-sim:default

    Testing logs before change (excerpt from sched/sched.c):

    /* No SPDX identifier present */

    Testing logs after change (excerpt from sched/sched.c):

    // SPDX-License-Identifier: Apache-2.0

In short, the PR description needs to be significantly more detailed and explicit to meet the NuttX requirements. It should provide specific information about the changes, their impact, and clear evidence of testing.

Xiaomi has submitted the SGA and we can migrate the licese to ASF

Signed-off-by: Alin Jerpelea <[email protected]>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
@jerpelea
Copy link
Contributor Author

jerpelea commented Dec 18, 2024

@xiaoxiang781216 please ignore can nxstyle errors

Copy link

@cederom cederom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @jerpelea :-)

Copy link

@cederom cederom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Some code changes slipped in causing build errors that needs to be fixed?
  • Maybe also good moment to fix reported code formatting issues?
  • Or just update SPDX headers without touching the code?

Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <[email protected]>
@jerpelea
Copy link
Contributor Author

@xiaoxiang781216 ready to go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants