Description of problem:

Currently, the Red Hat Repositories page offers all content provided by the Satellite's Manifest in a Cascading fashion where all available listings are listed on a per-product bases.

For example, when expanding Red Hat Enterprise Linux Server, and then for RHEL 7, we get a list including the GA Minor releases and the base available full content: 7.0, 7.1, 7.2, 7.3, and then 7Server.

People commonly misunderstand the purpose of the minor release repositories and then reason they exist, and how they can be properly used.

There needs to be a common understanding that these repositories (minors) are dead from their moment of of the next minor's inception. They exist as a snapshot in time up to the GA of the next minor release. Once we move past a given minor release, there will never be updates, fixes, or security inclusions into those particular repositories.

The only exception to this are the EUS Minor release repositories (In the situation of RHEL). These would need to be handled differently.

The goal and initial proposal we are bringing for this is to make the following modifications:

1. For RHEL Minor release repositories (Non-EUS), we should list them under a different tab or category within the Repositories page (This could be listed as Unsupported/Limited Support, or even more simple as "Prior/Non-Current Releases"). This tab should provide a prominent note/warning of what to expect when using these repositories, and perhaps a link to the Satellite blog posts by Rich Jerrido explaining this content.

2. For RHEL Minor release respositories (EUS), we would need to find a different way to categorize. There will always be a few releases that are currently in support and therefore, we would not want to list them on a page where the assumption is that they are old/unsupported.

There are a few ways to think about handling this. One that strikes me as a possibility would require buy-in from Candlepin. The simplest way to get information to every Satellite about what is currently supported and how it should be categorized in the Satellite WebUI/Repo page would be to include metadata within the Satellite manifest that could indicate EOL dates for repositories which can be referenced by Katello to manipulate how data is presented in regard to these items.