Handlers schema for other features

[Trenly]

Description of the new feature / enhancement

• Related to Package Tombstones #1900
• Related to Support redirecting manifests #1899
• Related to Identify community members that usually update specific packages. winget-pkgs#29323
• Related to Restrict access to manifests for packages winget-pkgs#100

Much of these ideas rely on information on how to handle the manifest information, or to provide additional information that isn't intended to be in the package manifest. These ideas are currently suggesting individual Yaml files for their implementation. However, it should be possible to have all of this information in a single Yaml file and have an associated schema.

This would reduce any potential clutter from having files on how the application and other integrations would behave.

If included with a manifest submission, should be accepted by the pipelines. If the handlers contain only Tombstones and Maintaner-Users, community mods could be able to approve. If the handlers contain a redirect, robots handling, or Maintainer-Approvers, add a specific label and assign to a MSFT engineer for review

Proposed technical implementation details

A handler file could look something like this, and would be valid at the package or version level. If there is a handler at the version level and the package level, both should be considered, and any conflicts should be resolved by giving preference to the version level handlers.

# Handlers.yaml
Redirect:
  Type: <redirect type>
     # soft - optional redirect 
     # hard - required redirect
  PackageId:  <New package identifier> # Where the package redirects to
Tombstone:
  # I know this is a single field, but should still be an object in case additional metadata needs to be added in the future
  Reason: <Why this version/package tombstoned>
    # Examples -
    # Download not available
    # Interactive only installer
    # Cannot be validated
    # Dynamic CDN
    # Publisher request
Maintainers: # 
  Users: # Who usually updates this package or has knowledge about it
    - jedieaston
    - OfficialEsco
  Approvers: # These people might be able to act as moderators for this specific package without being community moderators
    - Trenly
   Owners: 
    - Verified publisher metadata suggested from issue 100 linked above
Robots:
    SkipAvailabilityCheck: <whether wingetbot should check if this package is available>
    CheckInterval: <how often to check the urls>
    # This gets down to what the SLA is for keeping packages up to date. Maybe some packages only need to be checked for upgrade/ availability
    # once a day, maybe some only update once a week. Just something to consider for the future
    ManualUpgradesOnly: <if a new version is detected, create an issue and mention all the maintainers instead of having the bot try to update it>
    # Additional keys here to control how the repository bots interact with the package
ManifestVersion: <1.3?>

[denelon]

Another related Issue #910

[denelon]

I think I like where this is going. We've gone back and forth as to whether it should be one or many files. In some cases, we're only going to allow a verified developer to do things, so that metadata may only be modifiable by someone at Microsoft following official policy.

Having to check two places in the event there is a file at package level or version level can be complicated. We have avoided attempting to deal with conflicts as users might not know to look in multiple places. The Tombstone feature was the first to consider files at both locations.

The bigger the file gets in terms of scope, the more likely we could have a merge conflict, and we want to avoid that as much as possible. Maybe we can only allow only one PR to be open for one of these files at a time to help reduce this liklihood.

[Trenly]

I think I like where this is going. We've gone back and forth as to whether it should be one or many files. In some cases, we're only going to allow a verified developer to do things, so that metadata may only be modifiable by someone at Microsoft following official policy.

Having to check two places in the event there is a file at package level or version level can be complicated. We have avoided attempting to deal with conflicts as users might not know to look in multiple places. The Tombstone feature was the first to consider files at both locations.

The bigger the file gets in terms of scope, the more likely we could have a merge conflict, and we want to avoid that as much as possible. Maybe we can only allow only one PR to be open for one of these files at a time to help reduce this liklihood.

That's true. The other thing we could do is to merge this concept with the .validation files; Something like -

Waivers:
  - PackageVersion: 1.0.0
    TestPlan: Validation-Domain
    WaiverId:   '{00000000-0000-0000-0000-000000000000}'
  - PackageVersion: 1.0.2
    TestPlan: Validation-Domain
    WaiverId:   '{00000000-0000-0000-0000-000000000000}'