Catalog Health 2021/06/02

[denelon]

We're going to have a heavy focus on catalog health for the next few months.

Our AMAZING moderators have been pouring their time into making the catalog and the end to end experience with the Windows Package Manager better.

This is an ask for them to identify the top three features, we should look at for the next release. I can't make any promises based on our engineering capacity, but I want to make sure we're focusing on the most important features to help here. You may already see some Issues with the "Catalog-Health" label.

@ItzLevvie
@jedieaston
@OfficialEsco

Please let us know what you think are the next most important features you would like us to work on. This could be for any of the following areas:

• Windows Package Manager Client
• Windows Package Manager Community Repository Validation Pipelines
• Windows Package Manager Manifest Creator

For the rest of the community:
We will still continue working on other areas like support for dependencies, PowerShell cmdlets, and other improvements. The best way to let us know if a feature is important is to add a 👍 to the Issue. Please don't add comments to these Issues unless you have something to add related to implementation or examples. Additional comments make it harder to read the Issues.

[jedieaston]

My list (specifically for Catalog Health issues, which is why I'm not listing the power couple of dependency and .zip support):

1. Schema extension to support multiple ARP entries (or a single entry, I guess, where PackageName/PackageVersion != name/version in ARP): Schema extension to support multiple ARP entries. winget-cli#1073. Maybe biased because I opened it, but we really need a way of specifically saying "this manifest runs this installer that puts these entry/entries in the ARP table" so that we don't have to decide whether we want upgrades to work or we want friendly/correct PackageNames/PackageVersions/etc.

2. Multiple URL support for wingetcreate: Multiple URL support winget-create#53. This is sorely needed because if a manifest has more than one installer, it can no longer be updated by wingetcreate, making it unusable for a lot of the catalog (and any app that wants to use it in their CI/CD process and can't because they need more than one installer).

3. wingetcreate update does not update the ProductCode and will keep the previous one like wingetbot. wingetcreate update does not update the ProductCode and will keep the previous one like wingetbot. winget-create#22. (and The bot doesn't know that ProductCode changes in a new MSI. #12167 for the issue with wingetbot). I know there's not a super great API for pulling apart a MSI file unless you have access to .NET Framework on a Windows box, but this seems like low hanging fruit compared to some of the bigger problems. (I'd take a look at fixing the bot, but that's not open source.. yet...)

The big headache right now is that wingetcreate and wingetbot, the two tools Microsoft has put out there to create manifests, are both committing incorrect metadata sometimes which we have to clean up (things that don't match the ARP table, incorrect ProductCodes, etc). I know it's better to get an MVP out there and collect feedback than try to waterfall, which is why I'm happy to open issues and moderate. But it is the major headache right now.

[jedieaston]

Just wanted to note that all of these issues have been closed. Thanks everybody!

[denelon]

Given the 👍 from our other moderators, We will spend some of our resources bringing these three issues towards the vey top of the backlogs.

[jedieaston]

Awesome! Thanks for listening.