Repository navigation
Time to address the elephant in the room: There are too few users with PR merging rights who merge PRs. #333585
Description
#333536 makes me think the time is right.
Essentially:
- Only 1¼ admin ever goes through packages (Stephen Gillie, with the ¼ being denelon).
- PRs for new packages average well over a week before they get merged… and that's when counting from after the PRs first get their
Validation-Completedtags. - Tags that were (IIRC) never intended to be blockage causes, have ended up becoming ones because they result in processing times of ≥4 weeks.
Validation-No-Executablesis the most severe example (with# 329209elaborating partially on it). - PR processing times for new packages have got long enough that there's a fully possible risk that the devs have updated the download link URL upstream before the PRs get looked into. Most things related to KDE comes to mind, for instance
# 332112. - Winget-pkgs PR submitters on GitHub can't be expected to join the ElementIO server to have their PRs processed.
- Processing times are long enough that admins can't remove incorrectely given blockage tags in time on PRs that aren't actually blocked, before the pipelines auto-close the issues due to time limits (See
# 329263and# 333533).
The 2 possible solutions are the same as in similar cases throughout GitHub where PR backlogs have got out of control:
- Give additional users PR merge rights.
- Have additional users with existing merge rights go through the open PRs on a weekly-or-more-often (per user) basis.
Activity
denelon commentedon Jan 26, 2026
Imre Eilertsen (@DandelionSprout)
We're at an inflection point in terms of the number of PRs being submitted and the ability for the infrastructure to gracefully handle the load of automated validation. We have some large changes in progress:
The project gives a view of items currently deemed "important" to work on next.
I've had to make some tough calls relative to the number of Microsoft folks who have PR merge rights and should focus on manual reviews vs. improving the infrastructure. Right now, I'm optimizing for getting these big changes implemented and released.
I see this issue as more of a "call to action" or a "discussion" as opposed to a feature or bug to be implemented. I'm going to go ahead and convert it to a discussion.