Time to address the elephant in the room: There are too few users with PR merging rights who merge PRs.

[DandelionSprout]

#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-Completed tags.
• 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-Executables is the most severe example (with # 329209 elaborating 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 # 329263 and # 333533).

The 2 possible solutions are the same as in similar cases throughout GitHub where PR backlogs have got out of control:

1. Give additional users PR merge rights.
2. Have additional users with existing merge rights go through the open PRs on a weekly-or-more-often (per user) basis.

[denelon]

@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:

• WinGet (view)

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.

[DandelionSprout]

• "(…) as opposed to a feature or bug to be implemented."

I guess you're technically right about that, now that you mention it.

[denelon]

Most of our "moderators" are community members. They have the ability to "moderator approve" PRs that have passed the automated validation steps. They don't necessarily have all the insights into what went wrong when something doesn't just flow through the system. There is only so much they can do, and they are volunteering their valuable time and knowledge.

Handling the exceptional cases (I think of these often as "known classes of problems") often requires someone from Microsoft to review. These are where the most time is consumed for people working on the project.

The following Issue has a list of known classes of problems:

• [New Feature]: Validation Pipeline (known classes of problems) #325593

We see those as areas where it takes more "human" time that generally extend the average time from PR submitted until the package version has been published. We will be prioritizing the ones that have the biggest impact in terms of the amount of time that class of problem impacts our overall throughput.

We've been doing a lot of work behind the scenes to improve visibility for what went "wrong" or why a PR "failed" automated validation. When we have our next big release with the GitHub App and a few other improvements in progress (like queueing) we're expecting to reduce the time it takes to investigate. It should also surface more information directly on the PR in the form of comments as opposed to requiring someone to go spelunking in log files.

[DandelionSprout]

• "We see those as areas where it takes more "human" time that generally extend the average time from PR submitted until the package version has been published."

So do I for sure.

• "It should also surface more information directly on the PR in the form of comments as opposed to requiring someone to go spelunking in log files."

I approve of that idea. After all, the automated pipeline comments are usually things like (paraphrased) "We unfortunately couldn't install this silently. Please do some changes and submit again.", while ValidationResult.zip and increasingly also InstallationVerificationLogs.zip hold the actual info to some extent; and even then they are less than intuitive to access unless one already knows how to access them:

1. The pipeline links usually have to be opened in a private tab, since if they are accessed while logged in with a relatively normal Microsoft user account will throw an error of not having sufficient rights to view the page.
2. Even while on that page, one has to click on "\d artifacts" to get the true logs, as the regular logs will in 80% of cases just say (paraphrased) "[Result] Fail".

[denelon]

Exfiltrating logs from a hardened environment requires extra scrutiny. We're working on making it easier to get to the logs, and we're working on more clear error messages to help understand the actual reason things failed. The "Internal-Error-Dynamic-Scan" is tantamount to a generic exception and is rarely helpful.

The goal is to be able to explain in understandable terms what went wrong so it's easier for someone to understand what needs to be done.

[jamesaepp]

Just thinking out loud.

I like winget. I think it's one of those things MSFT is still mostly doing right (compared to a lot of other divisions I could roast).

However, the key thing I see here is a staffing ($$$) issue. Microsoft isn't committing the resources to winget which is an incredibly important project to holding up the broader security of the entire Windows platform. Microsoft, via winget, helps developers keep their software deployed to end user machines faster with the least amount of trouble.

What's the security cost of NOT getting third-party vulnerabilities on Windows patched? Why is Microsoft not investing in the staff? Wouldn't staffing this project appropriately directly support a "secure by default" mission?

Sounds to me like there is a direct parallel between this discussion and the very origins of Winget. Microsoft is cutting corners.

[UnownPlain]

3rd party sources do exist but there aren't many public ones. I found this one online but it looks like it's unmaintained.

I also found one that simply just mirrors the community repo at https://cdn.winget.microsoft.com/cache

[denelon]

Is there a reference for:

Though what I know about how Microsoft very-very-much-higher-ups think of Winget

The REST API is something I decided to build so enterprise customers could stand up their own private sources to distribute private line of business packages and use as a curated set of approved packages. I never expected or intended to have a large set of sources. WinGet could support that, but other than developers, power users, and IT administrators are a relatively small number of users in the Windows ecosystem. CLI tools generally aren't very popular with consumers.

The community repository wasn't a "thought experiment" or a "proof of concept". It was genuinely intended to provide a way for reducing the friction involved in distributing "developer tools". I've spoken about it several times at conferences (many of those are online).

There is no shortage of future improvements or enhancements for both the "community" use cases or "enterprise" use cases I'd like to enable. One of the ones I'm digging deeper into currently is:

• Checking for known vulnerabilities winget-cli#2204

[DandelionSprout]

• "The community repository wasn't a "thought experiment" or a "proof of concept". It was genuinely intended to provide a way for reducing the friction involved in distributing "developer tools". I've spoken about it several times at conferences (many of those are online)."

Good to know.

• "Is there a reference for:"

Give me 20min and I'll see if I find it.

[DandelionSprout]

I could've sworn that marketing that lead up to the release of Windows Server 2025 focused on that it was a way for companies to create their own repos to internally distribute/deploy apps approved/added by the companies' IT teams. But I haven't been able to find it again, and instead https://learn.microsoft.com/en-us/windows/package-manager/package/repository came up much more prominently when I searched around on Qwant and Google.

As such, I apologise for my insufficiently founded claims.

[denelon]

No worries. I would not have been surprised to see unique claims made by others. I would have contacted them to have a discussion. It took a lot of effort to have WinGet included in Windows Server. I tried for a few years until it actually became one of the top requested features for the Windows Server team. In the end, they actually approached me about what it would take in terms of product development, and fortunately we had already prioritized the work that could have prevented success. It can be very interesting getting things done in such a large organization. Many of the features being launched/released were years in the making (even features that are trivial in terms of software engineering).

As an aside:

I really appreciate the interest in helping make WinGet become the best product it can be. Discussions like this can be challenging, but I'd rather be open and transparent. I can also be convinced to change my mind, and even when I don't necessarily like it, I'll admit when I'm proven wrong (this happens regularly).

I can only imagine how challenging it is to reason about what's going on with validation since it's not open source. The reality is that we're using a hardened infrastructure designed not to let PUA (Potentially Unwanted Applications) get out into the wild. We have to assume that every package we're validating contains nefarious code. That adds a bunch of complexity. We've come a long way from the days when I used to manually validate every single PR myself, or I had to find someone else to validate packages I submitted. This is just another one of those points in time where we're hitting growing pains.