sched_unlock: remove redundant/stale logic and comment

[yamt]

Summary

sched_unlock: remove redundant/stale logic and comment

Impact

no functional changes are intended.

Testing

esp32s3-devkitc

[nuttxpr]

[Experimental Bot, please feedback here]

Fill In The Commit Message: This PR contains a Commit with an Empty Commit Message. Please fill in the Commit Message with the PR Summary.

Yes, this PR appears to meet the basic NuttX requirements in form, but it lacks crucial details to be truly considered complete. Here's why and what's missing:

Strengths:

• It follows the required template.
• It provides a basic summary of the change.
• It identifies the target tested.

Weaknesses & Missing Information:

• Insufficient Summary: "remove redundant/stale logic and comment" is too vague. What specific logic and comment were removed? Why were they redundant/stale? What problem did this redundancy/staleness cause (even if it was just code clarity)? A more concrete example is necessary.
• Missing Issue References: Are there any related issues in either the NuttX or NuttX-apps repositories? Even if not, explicitly stating "N/A" is better than leaving it blank.
• Incomplete Impact Assessment: While stating "no functional changes are intended" is good, it needs more detail. Even seemingly minor changes can have unexpected impacts. Specifically address all impact points, even if the answer is NO. For example:
  • Impact on user: NO
  • Impact on build: NO
  • Impact on hardware: NO
  • Impact on documentation: NO (or YES if the documentation referenced the removed logic/comment)
  • Impact on security: NO
  • Impact on compatibility: NO
  • Anything else to consider: NO
• Missing Build Host Information: What system was used to build NuttX? (OS, CPU architecture, compiler version). This is crucial for reproducibility.
• Absolutely No Test Logs: This is the biggest problem. The PR claims the changes work as intended, but provides zero evidence. Without "before" and "after" logs, there's no way to verify the claims. What tests were run? What was the output before the change? How did the output change after the change (even if the change is meant to be non-functional, demonstrating that behavior through logs is important)?

In short: The PR needs significantly more detail, especially in the Summary, Impact assessment, Build Host information, and, most importantly, the Testing section with actual logs. While the template is followed, the content is insufficient for proper review.