nuttxpr commented on PR #16029: URL: https://github.com/apache/nuttx/pull/16029#issuecomment-2742536070
[**\[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: * **Summary:** While it links the issue, the summary lacks a clear explanation of *how* the fix works. It mentions changes to buffer handling in `ioctl`, but doesn't detail the implementation. Example: "This change modifies the `ioctl` handling in `cdcacm` to correctly track buffer status separately from the USB request buffer, resolving discrepancies with standard serial driver behavior for querying RX/TX buffer levels and clearing buffers." * **Impact:** Stating "CDC/ACM" is insufficient. Be explicit. Are new features added? No. Are existing features changed? Yes (buffer management within the CDC/ACM driver). Address *all* impact points. Even if the answer is "NO," explicitly state it for each item. For example: * Impact on user: YES (Applications using `ioctl` to query or clear CDC/ACM buffers will now function correctly). * Impact on build: NO * Impact on hardware: NO * Impact on documentation: YES (If this behavior wasn't documented or was documented incorrectly, it should be updated.) or NO (If the behavior is already correctly documented) * Impact on security: NO (Unless the buffer handling issue had security implications) * Impact on compatibility: Potentially YES. If applications relied on the buggy behavior, they might break. Explain this. If no compatibility issues, state NO. * Anything else to consider: NO (or mention anything specific) * **Testing:** Insufficient. * **Build Host(s):** Specify OS, CPU architecture, and compiler version used for building. Example: "Linux, x86_64, GCC 12.1.0" * **Target(s):** Be more specific. "esp32s3-devkit board" is okay, but adding the NuttX configuration used is better. Example: "esp32s3-devkit board with `nsh` configuration." * **Logs:** Providing actual log output *before* and *after* the change is crucial. This demonstrates the issue and confirms the fix. Don't just link to the issue; include relevant snippets showing the incorrect and then the corrected behavior. Example: ``` Testing logs before change: (demonstrates the issue with ioctl and buffer counts) ``` ``` Testing logs after change: (shows the ioctl calls returning the expected values after the fix) ``` By addressing these points, your PR will be much more likely to be accepted. Clear, concise, and complete information helps reviewers understand your changes, assess their impact, and verify their correctness. -- 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
