nuttxpr commented on PR #15179: URL: https://github.com/apache/nuttx/pull/15179#issuecomment-2541026079
[**\[Experimental Bot, please feedback here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues) No, this PR description does not fully meet the NuttX requirements. Here's why and how to fix it: **Missing Information in Summary:** * **How does the change exactly work?** This is the most crucial missing piece. Describe the mechanism used to read and write files. Does it use the standard C library? Does it interact with the NuttX file system? Are there new APIs? Provide specifics. * **Related Issues:** If this addresses a specific issue in NuttX or NuttX Apps, link it. Even if it doesn't directly address an existing issue, consider creating one to track the feature request/bug that this PR solves. This helps with traceability and project management. **Incomplete Impact Assessment:** * **Is new feature added? Is existing feature changed?** Specify explicitly: "Yes, a new feature is added to the null audio driver." * **Impact on user:** While you mention "conveniently customize," you need to be more specific. Will users need new configuration options? New APIs? Will existing functionality be affected? * **Impact on build:** Does this introduce new dependencies? Does it require any changes to the build system (Kconfig, Makefiles)? * **Impact on hardware:** While it's likely "NO," explicitly state it. * **Impact on documentation:** If this new feature requires documentation updates (which it likely does!), state "YES" and explain what documentation needs to be added/modified. * **Impact on security:** Consider the security implications of file access. Even if minimal, explicitly state "NO" and briefly justify why (e.g., "No impact on security as file access uses standard NuttX mechanisms"). * **Impact on compatibility:** State "NO" if there are no compatibility issues or explain potential issues if any. **Insufficient Testing Information:** * **Build Host(s):** Be specific about your development environment. Example: "Linux (Ubuntu 20.04), x86_64, GCC 9.4.0" * **Target(s):** Which architecture and board configuration did you test on? Example: "sim:nsh", "qemu-rv:hello", "stm32f4discovery:audio" * **Testing logs before change:** These logs are essential to demonstrate the problem this PR solves (if applicable) or the absence of the new feature. Even if adding a new feature, show the previous behavior. * **Testing logs after change:** Provide clear evidence that the new functionality works as expected. Show examples of reading and writing audio data. Demonstrate the success of the key use cases you are trying to enable. "CI" is not sufficient; you need to show the actual test results. **Example of a Better Summary:** > This patch enhances the null audio driver by adding the ability to read and write audio data from files. This allows developers to easily create customized audio streams for testing and debugging purposes. The implementation uses the standard NuttX file system APIs (`open`, `read`, `write`, `close`) to access files. New configuration options (`CONFIG_AUDIO_NULL_READ_FILE` and `CONFIG_AUDIO_NULL_WRITE_FILE`) have been added to enable this functionality. This addresses the need for a more flexible and controllable audio source/sink for testing, as discussed in [NuttX Issue #XYZ](link-to-issue). By providing more specific information in each section, you'll make it much easier for reviewers to understand, evaluate, and merge your PR. Remember to follow the guidelines in the `CONTRIBUTING.md` document. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
