What I propose is: As part of the retirement process we add the to
  Obsoletes: foo < %{latestversion+1}
And during upgrade from F37->F38 the package will be removed.

I am not a fan of this part. One release cycle seems awfully tight for this, and it also doesn't give the user an obvious override. I have had packages in the past hang around (I recently cleaned off some f27-era packages from my laptop when I upgraded it to f31) and then cleaned them off manually (listing them through `rpm -qa | grep fcXX` and then manually removing them), but I think it would be better to warn on upgrade when those packages don't exist in the newer release to tell the user they aren't around. Then they can make the decision on what to do with them. (how this is exposed in UIs, I am not sure).
If the user wants to preserve the package (e.g., because it moved to
Copr), he simply uninstalls and protects the installation of
fedora-retired-packages. But that will be an informed decision.

The benefits are:
 * we do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

How large a problem is this? I have had several f27-f30 packages installed on a machine that was successfully upgraded to f31 (and several others in between) with no issues. I am fine with saying if a package could cause upgrade issues then we explicitly remove it (like what was done for the python2 packages on the f31->f32 upgrade by marking them in fedora-obsolete-packages). I would imagine that this isn't a large problem for leaf packages at first, but could be a larger issue if a library they required was removed.

== Feedback ==

After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
discussion with fedora-obsolete-package maintainer] I filed this
Change proposal to include a wider audience.

See relevant [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK
thread on devel mailing list].

== Benefit to Fedora ==
 * We do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

== Scope ==
* Proposal owners:

Create package `fedora-retired-packages` as sub-package of
[https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
Edit https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
guidelines with:

The retired package should be obsoleted by one of:

 * fedora-obsoleted-packages - if the package can cause problem during
upgrade to next version of Fedora
 * fedora-retired-packages - in all other cases

Isn't this split between the two packages basically saying this change doesn't have the second benefit that is claimed above? If packages that would break an upgrade are added to fedora-obsolete-packages, then the only benefit left would appear to be that no unmaintained packages are left on a user's machine - the archaic packages that could break an upgrade can already be fixed by adding them to fedora-obsolete-packages without this change.

It is enough to open an issue on

* Other developers:
No other work should be necessary.

* Release engineering:
This is optional. I may work with rel-eng to change
to automatically create PR for `fedora-obsolete-packages`

How would unretirement of a package marked in fedora-retired-packages work? Would there be a similar automatic method to unretire the package and push an update to the fedora-retired-packages package so that it can be installed again? Would this list of retired packages be checked on every transaction, or just on system upgrades?
* Policies and guidelines: As stated above
will need an update.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.

User may opt-out by:
$ cat /etc/dnf/dnf.conf

This seems very drastic if the user just wanted one package to stay. This would basically revert to the old behavior in that case.