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

   [**\[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 as described.  Here's 
why:
   
   * **Insufficient Summary:**  The summary is too vague. It needs to explain 
*why* a smaller lock is desirable.  What problem does it solve? What are the 
benefits (e.g., performance improvement, reduced deadlock risk)?  How does the 
change *exactly* work?  Just saying "replace big lock with small lock" isn't 
enough detail.
   * **Incomplete Impact Assessment:** Simply stating "esp32_rtc" doesn't 
address the specific impact questions.  Consider each point (user impact, build 
impact, hardware impact, documentation, security, compatibility).  Even if the 
answer is "NO", explicitly state it for each item.
   * **Missing Testing Details:** "ci" is insufficient.  Specify the *actual* 
build host and target details (OS, architecture, board, configuration). Provide 
*meaningful* test logs that demonstrate the issue before the change and the 
improvement after the change.  What were you testing?  What were the results? 
Show concrete evidence that the change works and has the intended positive 
effect.  Just saying "ci" doesn't prove anything.
   
   
   **Example of a better Impact and Testing section:**
   
   **Impact**
   
   * Is new feature added? NO
   * Is existing feature changed? YES (The locking mechanism within the 
esp32_rtc driver is changed.)
   * Impact on user (will user need to adapt to change)? NO
   * Impact on build (will build process change)? NO
   * Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES (This 
change specifically affects the esp32s2 architecture and the esp32_rtc driver)
   * Impact on documentation (is update required / provided)? NO
   * Impact on security (any sort of implications)?  NO (Assuming the smaller 
lock provides equivalent protection)
   * Impact on compatibility (backward/forward/interoperability)? NO
   * Anything else to consider?  Potentially improved performance due to 
reduced lock contention.
   
   **Testing**
   
   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): esp32s2:esp32s2_saola_1
   
   Testing logs before change:
   
   ```
   # Demonstrate the problem before the change.  For example:
   # Measured RTC access time: 10ms (showing high latency due to lock 
contention)
   # or:
   # Observed deadlock scenario when accessing RTC from multiple threads.
   <Insert actual logs showing the issue being addressed>
   ```
   
   Testing logs after change:
   
   ```
   # Demonstrate the improvement after the change.  For example:
   # Measured RTC access time: 1ms (showing reduced latency)
   # or:
   # No deadlocks observed during concurrent RTC access.
   <Insert actual logs showing the positive effect of the change>
   ```
   


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