I think the knee-jerk consensus on our side is that we will be combining addons and unsupported under just unsupported going forward. This is of course subject to argument and change. But the unsupported link will be (for now):
All links here are the Math department's mirror, but it is very capable hardware. You can use
springdale.princeton.edu for the primary mirror but it won't gain you much. https and rsync are also available, and whenever possible, having your own copy on-site via rsync is the best way to go, especially for multiple installs.
The unsupported repo is already out-of-tree for core on Springdale < 8. The name "unsupported" also is pretty clear as to the warranty we provide for these packages.
SCL typically has provided software which is newer than what was released in core, with some method such as environment-modules to enable overrides of the core versions. Since 8 is still very new, there hasn't yet been a need for this, so there is no link I can provide here.
Indeed we're all busy. If you're prepared for Springdale 8, I'd say go for it. It installs well with way newer software and is fast and reliable. I've got some new hardware to run a Springdale 8 puppet server but it's not ready yet, which I need before I build out workstations for users. For now, I do have several basic VMs running Springdale 8 for some more basic tasks like web servers. I've been building packages for Springdale out of EPEL and Fedora and we're merging them as fast as possible.
Upcoming will be some Springdale specific packages which provide yum repo files, such as springdale-unsupported package. So in this way you will eventually not need to know these links.
RHEL 8 infrastructure has been a headache. Their build system has changed dramatically with this release. Vendor support is still very much lacking for things like drivers and management tools. We're not alone in this; CentOS took a long time as well to produce their builds. For additional headaches, I suggest checking out AppStream, with which you'll want to be at least vaguely familiar if you plan to build your own packages on-site.
Ben