[Feature request] Flag packages out-of-date

[robinhood2014]

I'd like to request a feature for Chocolatey; namely, the ability to flag packages out-of-date a la the Arch User Repository (AUR). I think such a feature might be helpful in alerting maintainers of Chocolatey packages to fix 404 errors.

┆Issue is synchronized with this Gitlab issue by Unito

[gep13]

@robinhood2014 thanks for raising this.

Can you point me at any examples of where this is used in AUR? What does this process actually "look like". There are existing mechanisms to reach out to maintainers of packages, so I am curious to see how this would help. Thanks

[robinhood2014]

Here's a list of packages that have been flagged as being out-of-date according to the AUR. https://aur.archlinux.org/packages/?O=0&SeB=nd&K=&outdated=on&SB=l&SO=d&PP=50&do_Search=Go

[gep13]

I guess I am still failing to understand how this helps.

What do consumers of these packages do with this information, and how does it help package maintainers to get things updated?

What are the workflows or processes behind this information.

Note, I know nothing about AUR and how things work over there in terms of package maintenance.

[AdmiringWorm]

I guess I am still failing to understand how this helps.

It can help in two cases from my point of view

1. It is an easy way for users of the package to notify any maintainers that the package is out of date (as well as reflecting that state to other users).
2. It can help when/if handing over the maintenance to new users by having a distinct time and date the package was flagged out of date (since maintainers also receive emails about it being flagged).

What do consumers of these packages do with this information, and how does it help package maintainers to get things updated?

Consumers in general would see at a glance that it is out of date, without actually checking themself or reading comments, and it can help maintainers as it is easier for consumers to notify them of updates instead of having to write a specific email to them instead.

What are the workflows or processes behind this information.

I would see the workflow and process be similar to AUR (although not the same).

1. A user flags the package out of date, and optionally provides additional details (like release notes, new locations of downloads, etc)
2. An email gets sent to the maintainer(s) that the package was flagged out of date, and with any details the user included.
3. The maintainer then have three options
   1. Unflag the package (in case of false flagging, or incorrect flagging)
   2. Update the package to the latest version
   3. Orphan the package so other maintainers can take over the maintenance of the package.
4. If no change has been made after 2 weeks, a user can then contact one of the Trusted Users (I don't remember if it is through the forum, or through email) and request being added, or file an orphan request to remove the current maintainer and make room for new ones.

Below is an example of the email that gets sent to maintainers (although without details in this one).

And after some time they could file for an orphan request (which is the next step, so new maintainers can pick up the package). (In the case of chocolatey, this would instead be the time that the user contacted the site admins)

A reference to some of the information: https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Requests