I may self really dislike Gnome. RHEL 8/CentOS 8 is leaking of KDE. We use the “KDE Plasma Workspaces” form EPEL. Works well.
Since CentOS8 will die, the existence of EPEL-Packages will become uncertain. It would be nice to see an “official” choose of the DE in Rocky.
Please include the “KDE Plasma Workspaces” equal to Gnome in Rocky. Like in Fedora.
I think this brings up another possible issue. What will the future hold for EPEL. It might be a bit ambitious to take it on right away, but should the packages currently available via EPEL be moved to a sub-section of Rocky?
assumption: rocky linux will be a server distro. Then pragmaticly thinking, why add a DE (any DE)?
as far as I understand, Rocky-Linux will be bug-to-but with RHEL, so far, whatever packages in RHEL will be in Rocky-Linux if that helps… I assume other contributors may build their own RPMS and create external repos same as any other distro.
Just to be clear: my remark was just to shake things up and getting things clear. Obviously leaving out DE’s is not within the boundaries of the Rocky-Linux goals.
Rocky-Linux will be bug-to-but with RHEL
So lest stick to What is there
However if we do go of extra Desktops let look at Cinnamon as well Please
Adriaan
All of this (KDE, Cinnamon, misc other stuff) goes in EPEL, not Rocky.
Why should EPEL go away? It is meant for RHEL as well as all other compatible ELs. And even if. There are other alternative repositories which are much more likely to pick it up.
But special packages/repos could be built and provided for Rocky Linux like CentOS SIG. But this is more like step z, when Rocky is at step a 
But Rocky is has to be a server oriented and it was announce as a bug-for-bug compatible with RH. Besides you can install whatever DE you want. What would be the problem?
Just use KentOS
How about having an option between multiple DE?
"But Rocky is has to be a server oriented "
I… beg to differ. I do the on-site Linux tech support to the scientists at CERN and we use Centos also on desktops because need something rock solid for development, data acquisition and data simulation.
And there’s plenty of other people who use it their desktop OS. If it was only for server use, there would no DE on it in the 1st place, would it? 
Since the point is to make a binary compatible bug-4-bug identical release changing the included packages in the default product is not something I would support.
I see a few viable options to try and provide the request while not “tainting” the core distribution.
The first option is the simplest, there should be no reason this won’t continue to work as it does today. The second (and third) options I only suggest if EPEL shuts down and “we” choose to provide alternative options to obtain packages previously maintained by EPEL.
The third option can obviously be selected by community members even if EPEL continues to exist. However similar to prior suggestions I think focus on the “task at hand” makes the most sense to keep the focus on current goals before the interest(s) of new SIGs.
I believe that Rocky Linux install process should follow that of CentOS/RHEL/etc. Anything outside of that should fall to EPEL or other RHEL compatible repositories. Adding too much beyond the RHEL base provides could result in too much overhead during the install process. Leave the DE respins for Fedora and Ubuntu (and its respins). The purpose of RHEL respins should be security and stability above all.
I have used Scientific Linux and CentOS in my professional career and never used GNOME or KDE in any of my workstations. Its usually been Cinnamon via EPEL the way it should be.
Rocky is announced as 1:1 to RHEL. If RHEL has it, so will Rocky.
Anything not in RHEL should not be in the main repos from Rocky.
Create an additonal repo for Rocky, for example “gold” (for what ever suits best) and anything additional like KDE, Cinnamon or Mate could be added from there. Depending on the use on ones system, users can use or ignore such an additional repo.
This is both the Strength and Weakness of Rocky Linux, CentOS 8.4, Alma Linux 8.4 and those OS’s that are descendants of RHEL they are TRUE "Bug-for-Bug copies of RHEL 8.x and beyond.
As a small matter IF you want top install KDE 5 in Rocky Linux 8.4 it can be done, but it is a PITA . Indeed I was never able to successfully install either CentOS 8.4 or Rocky Linux 8.4. It would a particular point in the install process then the install would throw up some type of ERROR message and the Install would come to a screeching HALT!! While trying to solve the install process, I came across a thumb drive of CentOS 8.3. It installed with no problems – though I had to install it something like 5 times because of USER ERROR. Once I had installed CentOS 8.3, I simply ran “dnf update” which rolled the system over to CentOS 8.4 This brings us back to your question of installing KDE (5.xx – unfortunately ). I am a long time – 20+ year – user of KDE, but KDE 5.x does not sit well with me and was considering jumping over to Cinnamon – which you can likewise install on CentOS 8.4.
My way around the CentOS 8.4 => Rocky Linux 8.4 was to do ALL – or at least most of all – my configuration in CentOS 8.4 BEFORE I ran the migrate2rocky -r command. In short bake in most of my configurations in CentOS 8.4 before I then migrated the whole to Rocky Linux 8.4, since, like you, I was not certain of HOW I would install KDE 5.x (now actually 5.18).
While there is a certain appeal to having a Bug-for-Bug compatible OS with RHEL, there are some MAJOR drawbacks to this approach. I discovered one such bug this past weekend that has been around for a L-O-N-G time but still has not been fixed, and the BUG affects ONLY RHEL 8.x, and of course, CentOS 8.x, and NOW Rocky Linux 8.4. The BUG deals with VMWare Player 15.x,y and 16.x.y. Just when you think you can start building or loading a Virtual Machine it throws up a “Exit Code 1” Error message. I ended up with the exact same “Exit Code 1” error message starting VMWare Player 15.0.0 all the way up to the Current Version of VMWare Player 16.1.2. As I said this is a well known BUG, but it remains UNFIXED. WHY?? Not a clue. Now could Rocky Linux FIX the BUG, or even deviate from the Bug-for-Bug ethos of RHEL?? Sure it could!!
Going back to the VMWare Player BUG, it exists ONLY in RHEL 8.x (… and CentOS 8.x and now in Rocky Linux 8.4; the BUG “Does Not” affect CentOS 7.9 as I have VMWare Player 16.1.2 running just fine on the Workstation, nor does it affect openSUSE 15.3 Leap, another OS I am currently evaluating as a replacement for CentOS. This brings us back to the Central Question for the Rocky Linux Team: Should Rocky Linux be an EXACT Bug-for-Bug copy of RHEL, or should Rocky Linux be committed to the BASIC idea of a Bug-for-Bug copy of RHEL, but tweaking their copy of RHEL but making it “their own” ie FIXING long standing BUGS that Red Hat seems neither to care about, or refuses to FIX. This is the equivalent – in some ways – of passing on a virus or disease which you know about, but which you refuses to take steps to mitigate. I am sure Red Hat will point their figures at VMWare, and I am equally sure that VMWare will point their figures back at Red Hat. It is the user of VMWare’s Player that bears the brunt of this BUG – truthfully I don’t care whose fault it is, I just care that the Bug be fixed. That the BUG does NOT affect CentOS 7.9 or openSUSE 15.3 Leap, and seems to be specific to ONLY RHEL 8.x, this is where Rocky Linux could play a huge role. There is nothing that prevents Rocky Linux from tweaking the Red Hat Code and fixing long standing bugs.
As to Robb’s assertion that “rocky linux will be a server distro. Then pragmaticly thinking, why add a DE (any DE)?” I disagree. I run a WORKSTATION and rely on KDE – even Red Hat provides a DE – GNOME – in their distro, and up until recently Red Hat provided both GNOME and KDE. To quote Robb, should Rocky Linux become a “Server Only” distro, then I can pragmatically predict that Rocky Linux will have a very short lifespan. The truth of the matter is that most of the people that are currently using CentOS Linux are a mixture of people who are running it on 1-2 machines as their primary OS so as to avoid paying the “Microsoft Tax”, and running an inferior OS on top of that, all the way up to small businesses, servers, and Super Computers. User experience ranges from noobys all the way up RHCE and everything in between. I use a DE (KDE 5.0) about 50% of the time and the CLI about 50% of the time. Why?? Because I have Parkinson’s Disease and as a result my typing skills suck! Using a highly configured DE such a KDE 5.x makes more than a little sense. …But I also have on this Workstation GNOME, Cinnamon, LDX, Mate, Xfce, and a few others. Why?? As backups, as well as DE for “Guests”, who might have some sort of preference… Plus while a CLI might be available to them, they will have really limited privileges, though more likely than not they will go shrieking through the house that there is a CLI in addition to a bunch of “pretty icons”. 
If Rocky Linux is going to succeed, then it has to reach out to whole bunch of different users or all types, it can NOT become pigeon holed as a server only OS.
I am currently casting about for an alternate to CentOS. One possibility which is not too horrible, is openSUSE 15.3 Leap. Where Red Hat is GNOME Centric openSUSE 15.3 Leap is KDE centric, though other DE are available as well. If you are coming from a Red Hat Environment, depending on how long you have been KDE, the learning curve can be quite steep. SUSE is a lot of non-standard procedures which can have you BASHing (hehehehe) your head against a wall. Both openSUSE and CentOS 8.4 have good things about and some really BAD things about them, but in reality it a coin flip at this time as to which is better and which is worse, at this point I give a microscopic edge to openSUSE 15.3 Leap, though this is subject to change.
+1 on that. I ran CentOS + KDE on my workstation and my laptop (as well as all our local school’s computers). But when Red Hat decided to ditch KDE on the desktop, I moved to OpenSUSE Leap, one of the finer implementations of a modern KDE desktop.
On my servers I don’t use a GUI, so I’m slowly moving from CentOS 7 to Rocky 8 (after a brief stint on Oracle Linux).
Right now if I were forced to choose between openSUSE 15.3 and Rocky Linux 8.4, as much as I would hate to do it, I’d choose openSUSE, and move Rocky Linux to a secondary status (I always have two OS’s – Primary, and Secondary on two different drives just in case of catastrophic disaster). I just seem to be forced to jump through too many hoops with Rocky: Amarok music player is missing and any excellent secondary music players such as Clementine are likewise missing; installing VMWare Player 16.1.2 which should be rather EASY, is anything but – but thanks to Ian I know it is at least possible, though I have yet to take the plunge since I have been having boot problems since my last round of hacking to try the workaround he proposed. RHEL / CentOS / Rocky Linux – 8.4 just seems to be an unpolished diamond in the rough.
OTOH openSUSE 15.3 Leap is far more complete – Amarok, and VMWare 16.1.2 went in without too much of a headache – but what is a headache is their non-standard command structure. Ex Instead of using /etc/bashrc like everyone else they use /etc/bash.bashrc which they tell you must not be changed and that you need to create a file called /etc/bash.bashrc.local. Trying to create a custom prompt in openSUSE becomes an exercise in madness. While instead of using dnf [command] as in RHEL / CentOS / Rocky Linux they use zypper [command] easy to get use use too, but then there is YaST. Probably the worst feature is that it locks the screens, goes to sleep and you can’t wake it up requiring a re-boot. All in all however, it has a much more polished look to it.
Right now I am waiting for the release of CentOS / Rocky Linux 9.5. I’m hoping by then the VMWare Bug will be fixed and that there will be at least 1-2 other music players, such as Amarok, included and that the whole will have a a far more polished feel to it.
In the meantime I am configuring both OS’s the exact same treatment. The one thing I have yet to add to either is zsh. I’ve done it once in leopard (current Workstation) but it was a bloody nightmare. I really want to exit BASH given the existence of “Dark Radiation”. Switching shells probably will not show the thing down much, but it might buy us a bit of time. Zsh is my chosen poison, but first you have got to get the bloody thing installed and configured.
I understand the frustrations of most of you in this thread. But as we all know, Rocky is based on RHEL. It’s meant to be enterprise focused and not meant to be an all-purpose distribution like openSUSE or Fedora (whcih is what I use) for desktops. That’s where EPEL, rpmfusion, elrepo, negativo17 come in for enterprise linux, to give you things that you may need to make a desktop experience more tolerable. There are also flatpaks too.
There is a desktop SIG in rocky that could, in theory, help package things that none of the aforementioned repos will provide you if you do not wish to deal with flatpaks. They won’t package KDE as that is already in EPEL, but there could potentially be other DE’s and addons that could show up in the future, not just for Rocky 8, but Rocky 9 next year.