Is your enhancement proposal related to a problem? Please describe.
Even though there is already a fair bit of automation for backports, it still relies on the manual step of applying backport tags such as backport v2.7-branch. At that point, a backport PR is created. With the volume of bugfixes that go into main, it is difficult for maintainers and release managers to see all of the candidate PRs that should be backported. It is quite possible that some bug PRs should be backported but have been missed.

Describe the solution you'd like
The vast majority of backports are legitimate and end up being merged into release branches. With that, it makes sense to automatically consider every bug PR that has been merged into main as a backport candidate. Then, the minority of backport candidates that should not be backported can be manually filtered-out.

This will rely on continued strong differentiation between bugs and feature enhancements on the part of the release / bug triage team. Of course, all backport candidate PRs should continue to be audited, but the process of creating them can be fully automated.

Propose running a script on a weekly basis to look at bug PRs that have already been merged into main.

Within the script, run the following approximate steps:

• For each supported release branch, check the PR merge date against the date the branch was made
• if merge date > branch date, add tag to PR for backport to branch

It's possible that there may be additional steps necessary for security-related backports.

There may be the occasional non-bugfix PR that also should be backported if it satisfies the criteria for "improving general stability". Since these represent a very small minority of backport candidates, it's acceptable to leave this as a manual process.

Describe alternatives you've considered
The status quo, but that is not scaling.

Additional context
Discussed in release meeting on 2022-03-01 (as well as the previous week).
cc @zephyrproject-rtos/release-team