nuttxpr commented on PR #14315:
URL: https://github.com/apache/nuttx/pull/14315#issuecomment-2413525421

   [**\[Experimental Bot, please feedback 
here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues)
   
   
   
   **No, the PR does not meet NuttX requirements.**
   
   **Here's why and how to improve it:**
   
   * **Summary:**
       *  **Missing Key Information:** 
           * **Why?**  Clearly explain the reason for these optimizations. Are 
there performance bottlenecks? Usability issues?
           * **What (in detail)?**  
               * How does the coredump parsing for xtensa work? What's the 
technical approach?
               * What specific logic is used to determine when ELF symbol 
loading can be skipped?
       * **Provide Links:** Include links to the actual PR and any related 
issues (even if you think there aren't any).
   
   * **Impact:**
       * **Too Vague:**  Saying "gdbserver.py" doesn't provide specific 
details. Address *all* impact points with "YES" or "NO" and provide 
descriptions where applicable. For example:
           * **Is new feature added?** YES (if this enables new functionality)
           * **Impact on user:** YES (users can now debug xtensa coredumps more 
effectively, potentially faster debugging if ELF symbols are skipped)
           * **Impact on build:**  NO (if the changes are only to the Python 
script)
           * **...and so on for all impact categories**
   
   * **Testing:**
       * **Insufficient Detail:**
           * **Build Host(s):**  Specify the OS, CPU architecture, and compiler 
version used for testing. 
           * **Target(s):** Be more specific. Instead of just "qemu mps3an547", 
provide:
               * **Architecture:** (e.g.,  RISC-V)
               * **Board:**  (e.g.,  qemu_mps3_an547)
               * **Configuration:**  Any specific NuttX configuration options 
used.
       * **Show Meaningful Logs:** Instead of "your testing logs here", include 
snippets of the logs that *demonstrate* the optimization's effect:
           * Logs before the change showing the issue (slowness, lack of 
coredump support).
           * Logs after the change showing the improvement (faster execution, 
successful coredump parsing).
   
   **Remember:**  A good PR is clear, concise, and provides all the information 
reviewers need to understand and evaluate the changes. 
   


-- 
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]

Reply via email to