Concerning Spins, I was referring to LXQt. Not sure if the issue has improved, but when I checked in 2023, most LXQt packages had been outdated for more than a year. The SIG does not maintain its packages but only uses what is available, since they have not the resources. Yet, we publish it as official spin without making users of the risks aware 
But many spins come without an aligned/tailored default configuration like KDE or Workstation (a pre-configured firewall ain’t a “kill” criteria but remains my favorite 
).
Not sure if such an approach is realistic. The reasons why packages are outdated is not always the same. There might be packages were no one had time or where the maintainer is no longer active or some pipeline was broken and no one recognized… That can be dangerous and imposes risks at the worst…
However, there are also cases when a package cannot be updated due to issues or due to dependencies, but that is still “under observation” by maintainers that ensure that no issues are related to that.
It cannot be automatically identified if and when a package is obsoleted, that’s part of the problem. Our upstream is very heterogeneous. So adding another “hop” in repos is not realistic imho. Also, having too few maintainers is already a problem. So increasing the work they have to do can increase the problem at the worst.
Unfortunately, a lot of users just want things to run and to be able to get installed… If packages are no longer available, many don’t care for the reason… and someone will then provide it elsewhere (which can worsen the actual risk on them).
My thought would have gone in the other direction:
Split the stable repo into “stable” as it is and “stable-safe” → stable is as usual, but stable-safe would only contain packages that we can ensure with a high probability that they are maintained, may it be by immediate updates, or by having someone to look after continuously it if it cannot be updated for some time for what ever reason… In short, a repo that avoids single points of failure. For example, the KDE SIG maintains packages that are effectively “observed” by the whole SIG. If something automated would fail, they would become aware of it. The same if someone forgets it: They regularly work with the packages the ship by default and align them. Both technical element and social/human elements are likely to be “corrected” by another one if any fails, given that a whole SIG has their eyes on it and the dependencies (even if just indirectly sometimes).
So users could then choose that they only want the stable-safe repo, and just change the default repo in their /etc/ → users then use either stable or stable-safe. With the latter, they ensure to get only packages with low probability of getting obsoleted or even risky.
One might add the possibility to collaborate: people who need a package but that is not yet stable-safe can engage with the maintainer and take the responsibility to regularly verify (and make a tick somewhere) if the package is still up to date. That is much less time intensive and needs less knowledge than packaging → a lot more people can engage here and invest time, and get their packages in stable-safe if they want. That might also help maintainers…
Obviously, the default should remain the normal stable repo… And then users can choose to replace stable by stable-safe. Just a thought
By the way, thanks for bringing this topic up!
