When enabling Red Hat repositories, there are some repository sets (i.e. rhel-7-server-rpms) that contain multiple release versions (i.e. 7.3, 7.4, 7Server). Those that are specific to a X.Y release will only provide updates for that Y stream.
Proposal
If you’re familiar with this page, you likely look for the 7Server release version so that any RHEL7 systems can get updates, regardless of which Y version they’re running. This feature aims to display the X.Y repositories in gray while emphasizing the XServer release version in bold. The grayed out X.Y repositories will also display an ‘i’ icon which explains: “This repository has a very specific update policy. Please see additional <link> documentation <link> prior to use.” Users may still enable whichever repositories they want.
As long as the documentation link is viewable to everyone, this sounds good to me. How are you determining which version to show, and which not to show?
Do we have automation to check for 404’d links? It is not needed as part of this RFC but might be good to add so the links to external sites mentioned in the codebase don’t go stale.
I believe the releasever field on the repository should be enough to determine if it’s specific to a Y stream, simply by format (X.Y). Do you think this is a reliable way to determine this information?
The repos have consistent naming so it should be fine to base it off looking for that format.
I think a warning triangle would probably be more appropriate than an info. There are better ways to freeze at a release than using those repositories (e.g. content views, or paying for EUS if you absolutely must be on X.Y for a prolonged period).
I will do a bold statement now: Everytime you need a documentation link, you are doing it wrong. And we fail in this on many places in Foreman core.
My 2c: Let’s explain this on the page itself in few sentences - maybe a UX from 90s would be a modal welcome screen with “Do not show again”. If there is not enough space on the page to explain what’s going on, we probably need to break this page into more pages. I think that this one needs to be a wizard for a very long time.
I tend to disagree with “Everytime you need a documentation link, you are doing it wrong.” There’s probably a wrong way to link to docs and a right way (why invest resources in docs if we don’t point our users there? Realistically, what kind of user reads all the docs beforehand? ). A ‘naked’ link probably isn’t a good idea, but a short 1-2 sentence explanation that suffices for ~90% of users with the option of digging deeper for the other 10% makes sense to me (I welcome your feedback).
Note that the proposed link for this issue (currently login-blocked https://access.redhat.com/articles/1586183) goes to a Red Hat article pertaining to RH content delivery and supported release cycles, so it is a bit different of a case than other Foreman doc links. This document covers edge cases, including why a user might want to enable a Y stream repository; distilling all of it into a sentence or two doesn’t seem feasible.
That’s indeed an extreme statement, I want to emphasize need of building such an user interface that teaches users naturally. I know it’s challenging, I don’t know how to do it, I somehow feel like wizards are good for this because you have plenty of space, multiple paths possible and option to “slow down”.
My comment was probably too generic, the (i) icon with explanation is a good addition. We need more of these. But ideally we would narrate whole process:
You are about to enable repositories, this is how it work at Red Hat in short (probably with link).
Which product do you want to enable? RHEL, RHEV, OpenStack, OpenShift, Satellite…
Okay, now update policy is as follows. (explained)
Which version do you need?
Are you going to kickstart as well?
Then which kickstart repo do you need?
Does not need to be wizard, this could be set of predefined filters with some explanation bubbles perhaps. I know that the structure you need to work with is simple and flat list of inconsistently named yum repositories, I believe we need a parser for that if there is not enough metadata.
What you’re suggesting does seem like a great approach, and I’d personally welcome a push from UX or PM to further improve this page in that fashion, but it definitely requires a great deal more work than what is proposed in this RFC.
Semi-related: we want to add an easy way to filter by product on the new RH repos page. Currently you can do so in scoped search, but its not very intuitive.
I’m discussing with UX and will open an RFE with mockups when they are ready.
And good luck.
). A ‘naked’ link probably isn’t a good idea, but a short 1-2 sentence explanation that suffices for ~90% of users with the option of digging deeper for the other 10% makes sense to me (I welcome your feedback).