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

   [**\[Experimental Bot, please feedback 
here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues)
   
   
   
   No, this PR does not fully meet the NuttX requirements.  While it provides a 
summary of the change and testing information, it lacks crucial details.
   
   Here's what's missing:
   
   * **Summary:**
       * **Why is this change necessary?**  What problem does it solve?  Why is 
aligning CMake with Makefile behavior important? What benefits does using 
`EXTRAFLAGS` in CMake offer?
       * **What functional part of the code is being changed?**  Be specific.  
Mention the files modified (e.g., CMakeLists.txt files).
       * **How does the change exactly work?**  Explain the mechanism.  Does it 
modify existing CMake logic?  Does it introduce new variables?
   
   * **Impact:**  Simply stating "N/A" is insufficient.  Consider these points:
       * **Impact on user:** Even if minimal, explain *why* there's no impact. 
Will users need to change their existing CMake invocations?
       * **Impact on build:**  Does this change the build process in any way, 
even if it's just adding a new option? If not, explain why.
       * **Impact on documentation:** If no documentation updates are needed, 
explicitly state that and explain why.  If documentation *is* needed, provide 
it or describe what needs to be added.
   
   * **Testing:**
       * **Build Host(s):** Provide specifics about your build environment.  
"ci-check" is not enough.  Mention OS, compiler version, etc.
       * **Target(s):** Be specific. "sim/nsh" is better than nothing, but 
mention the architecture (e.g., x86_64, armv7-m).
       * **Testing Logs:**  "ci-check" implies you rely on CI, but you should 
still include relevant snippets of the logs showing the behavior before and 
after the change, demonstrating that the change works as intended.  Even if the 
change is primarily about build process, show *something* (e.g., successful 
compilation with and without `EXTRAFLAGS`, or demonstration of the flags taking 
effect).
   
   
   In short, the PR needs to be much more descriptive and provide specific 
evidence to support the claimed changes and lack of impact.  More detail is 
always better in a PR, especially for a complex project like NuttX.
   


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

Reply via email to