mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
* Add change-request and manually-added-CODEOWNER lines to review checklist Reviewers who request changes now get their own line under each area their inline comments touch, whether or not they're a CODEOWNER or a requested reviewer. CODEOWNERS who are review-requested directly by a human (rather than auto-picked) get a separate required-approval line, and their approval is now required for that area's sign-off in addition to the usual reviewer's. * Prune reviewers whose area dropped out of scope A CODEOWNER requested for an area the PR used to touch, before a later push narrowed the diff, was never removed: touchedAreaOwners only reflects areas touched right now, so none of the existing avalanche pruning ever considered them. Reproduced live on PR #6528, where the branch's diff shrank to just .github/ but gheber/fortnern/mattjala (owners of unrelated areas) stayed as requested reviewers. Manually-added CODEOWNERS are exempt, since a human's deliberate request shouldn't be silently undone by a later push. * review-checklist: fix avalanche exemption regressing genuine avalanches #6524 exempted a review_requested login's whole area from avalanche detection to stop a manual re-request from being undone. But a genuine CODEOWNERS avalanche's own review_requested sub-events look identical to that case, and one of them can survive the ready_for_review vs. review_requested concurrency race (#6530: draft PR marked ready for review left all 3 CODEOWNERS owners requested instead of pruning to one, because the surviving run's action was one of the avalanche's own review_requested events, exempting the whole area). Replace the exemption with a forced pick: the directly-requested login still always survives, but now by replacing the rest of that area's avalanche instead of exempting the area from pruning — so a genuine avalanche still collapses to one person. Also gate justRequestedLogin on !isBotSender, matching updatedManuallyAdded's existing reasoning just above it: the bot's own requestReviewers calls fire this same event and aren't a human decision.