> Funny that people don't forget to create a PR when trying to make a change > but as soon as it is delivered the respective PR is "memory holed". We use the PR mechanisms for review but don't use the PR mechanism for merge. Makes sense that we open them since they're part of our workflow and forget to close them.
I'd *much* prefer a workflow where we just used the industry standard tools for both opening and closing (i.e. had per-branch patches we merged using gh after review passed and linked CI passed). But I suspect that's another [DISCUSS] thread and I should appropriately don metaphorical flame retardant protective gear before wading back into *that* particular dumpster fire. :D On Mon, Apr 14, 2025, at 8:27 AM, Mick Semb Wever wrote: > > > On Mon, 14 Apr 2025 at 10:23, Štefan Miklošovič <smikloso...@apache.org> > wrote: >> BTW If you still do not want to take care of closing it, that is also fine, >> because we have a script at least. >>>> > > > Relying on the PR name seems a bit brittle. Maybe it wouldn't take much to > improve it. > e.g. would it be possible to also auto-detect which PRs, still open, have no > changes to merge ? This is an easy indicator that the PR has otherwise been > merged. > Stale PRs with file conflicts is another lhf category that can get closed out. > > Not putting the work on you Stefan, just brainstorming…
