nuttxpr commented on PR #15076: URL: https://github.com/apache/nuttx/pull/15076#issuecomment-2523134283
[**\[Experimental Bot, please feedback here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues) No, this PR description does not adequately meet the NuttX requirements. While it touches on some points, it lacks crucial details. Here's why and what's missing: * **Summary:** While it states the overall goal (SPDX identifiers for SBOM generation), it lacks specifics. * **Missing:** Which tools are being referred to? What functional part of the code is changing (e.g., build system, kernel configuration, specific drivers)? *How* are SPDX identifiers being added (e.g., new Kconfig options, source code annotations)? A related NuttX issue number should be included if one exists. * **Impact:** Simply stating "SBOM" is insufficient. * **Missing:** All the "Impact on..." sections need to be addressed explicitly with "YES" or "NO" and a description if "YES." For example, if no user changes are needed, explicitly state "Impact on user: NO". If the build system changes, state "Impact on build: YES (New build options are added to enable SPDX identifier generation)." * **Testing:** "CI" is not enough. * **Missing:** Specify the host OS, CPU architecture, and compiler used for testing. List the target architectures and boards tested. Provide *actual* log output before and after the change, demonstrating the difference and verifying the intended functionality. If the change only impacts the build system, show the relevant build output. If it affects runtime behavior, show the relevant runtime logs. **Example of a better summary:** > This change adds SPDX license identifiers to the Kconfig files for core NuttX components to facilitate SBOM generation. Tools like [tool name] and [tool name] can now correctly identify the licenses of these components. This modifies the Kconfig files in the `nuttx/` directory and adds a new configuration option `CONFIG_SW_SPDX`. **Example of a better impact description:** > * Impact on user: YES (Users will need to enable `CONFIG_SW_SPDX` to include SPDX identifiers in the build output.) > * Impact on build: YES (The build system now generates SPDX tag output when `CONFIG_SW_SPDX` is enabled). > * Impact on hardware: NO > * Impact on documentation: YES (The Kconfig documentation and user guide will be updated to explain the new option and its usage.) > * Impact on security: NO > * Impact on compatibility: NO > * Anything else to consider: This change is a first step. Future PRs will add SPDX identifiers to other parts of the codebase. **Example of a better testing section:** > I confirm that changes are verified on local setup and works as intended: > * Build Host(s): Linux (Ubuntu 20.04), x86_64, GCC 9.4.0 > * Target(s): sim:qemu-x86_64, stm32f4discovery:nsh > > Testing logs before change (build output with `CONFIG_SW_SPDX=n`): > ``` > ... (relevant build output showing no SPDX info) ... > ``` > > Testing logs after change (build output with `CONFIG_SW_SPDX=y`): > ``` > ... (relevant build output showing SPDX tags) ... > ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
