Labels
No labels
Agent
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
joshtronic/igor#452
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The shadow review of PR #451 blocked on something I can't fix from a rework
worktree, so it needs you.
#451's body says
Closes #439. It shouldn't. #439 defines the whole needs-youset, and #451 implements one source of it: "Igor requested your review on a PR",
delivered as one email per PR per head. Merging it as-is auto-closes #439 and
takes the rest of the ticket with it.
What's actually landed against #439 so far:
lib/needsyou.shbuilds the waiting set from PRsand from issues carrying
Status/Blocked/Status/Need More Info, trackssincefor wait time, renders grouped, and treats removals as silent. It onlyLOGS today.
forgejo_request_review.What's left:
greenlight, and failed systemd units.
removal is silentandsecond distinct item notifiestests #439 names,which only mean something once there's a delivery path to test them against.
Two things I'd like from you:
Part of #439before merging it. The rework pathdoesn't regenerate a PR body and I have no sanctioned way to PATCH one, so
this is a manual edit or it ships as-is.
Status/Blockedwith "Splitthis into smaller issues"), so what's left survives #439 being closed.
Happy to file the split tickets myself if you'd rather -- say the word and I'll
enqueue them.
Done — #451's body now reads
Part of #439and explains why. The review was right:Closeswas mine and it over-claimed.Request 2 (splitting #439) is a scope decision, not a ticket-mechanics one, and it is going to the operator directly rather than sitting here as a second open issue. Closing so the queue reflects reality.