RHEL 9 Releasing very soon, Rocky 9 beta?

With it getting close to 6 months after the RHEL 9 beta and some talk about it possibly being released in a few weeks during the Redhat Summit [May 10th-11th], Is Rocky Linux going to prepare the infrastructure and a release a beta for Rocky 9 ahead of time? [So it’s a shorter time release between Rocky 9 beta → stable]

One of the biggest criteria moving to Rocky Linux is how fast it would update its own packages for security updates and especially major versions.

Alma Linux already has a 9 beta ready [ AlmaLinux 9 Beta--Now Available - AlmaLinux OS Blog ] so when RHEL 9 gets released, they have already mostly tested it and will have a MUCH shorter release time to stable where as Rocky 9 will fall behind and make users wait much longer.

1 Like

This is a common question we’ve received over the past few months. The reason why there hasn’t been word or announcements on Rocky 9 is because of the new build system we are developing to target this release and future releases going forward. Most of the conversation is taking place in our mattermost where we are bootstrapping 9 and troubleshooting along the way, as well as deploying the build system. A lot of this has been limited to our free time (as we’re volunteers making this all happen). We are always looking for help in this arena troubleshooting build failures and discussing strategies.

We are presently preparing and building out the new build system and using that to develop all future Rocky versions, as well as enable the community to participate in driving the future development and usage of the build system as a whole. This new build system, named Peridot, will allow us to produce and release Rocky major and minor versions in a fairly quick fashion, likely much faster than we currently do today with our current koji infrastructure. We are super excited to introduce this build system publicly to everyone when it’s in production and building 9 as well as building for our upcoming sigs!

Some derivatives may be out before we are, and this to us is fine. We are looking at this from a perspective of quality. We want to make sure we build a quality release for our users, not the fastest one. We are also looking at it from an enablement perspective, where our community can use this same build system sort of like a Fedora COPR or participate in SIG’s and drive development opportunities for the Enterprise Linux ecosystem. I definitely understand the concern of our fellow users having to wait until they can use some release. I totally get that, I was once in the same camp as a CentOS user! It is very, very normal for derivatives of RHEL to take some time before they release a X.0. It could be a month, it could be more. Check out the CentOS and Oracle release dates alongside their RHEL equivalents for an idea. Whatever the case may be, once that is out, releasing the next minor version some time later should be a piece of cake! (It did take us about a week to release our 8.5 after red hat released theirs; I was quite happy we were able to achieve that)

The way I and others look at it is that even if another derivative is ahead of us, we want to ensure our release is in tip top shape with the given amount of time we do have to work on this project day to day outside of our daily lives. If we only had more than 24 hours in a day! We have a great community of users that are willing to wait as long as they can before our releases and we have a lot of folks in the testing arena ready for when we release something usable, whether it’s a beta, an RC, or the potential gold images for 9.0 stable. Our testing team has been spending a lot of time getting OpenQA ready for this too, which will be awesome when it’s fully running.

With that being said, since January we have been building and bootstrapping for every architecture for RHEL 9 (s390x and aarch64 are the current low hanging fruit), building out the new build system and ironing out bugs over time, and adding last minute features to actually produce usable media for our testers in the testing channel in mattermost.

As a side note, we’ve done very well in releasing updates quickly in the Rocky 8 releases. We usually release updates within 24-48 hours during the regular cycles and we release minor version updates (8.5 for example) within 5-7 days. This time frame is to be expected with Rocky 9 as well even if we manage to produce packages and images quicker, on top of automatic notification emails to our mailing list, a rebuilt errata system, and potential beta releases of our own (our current koji infrastructure does not make any of this easy, this is why we haven’t been able to release even a Rocky 8.6 beta, let alone use the current infra to bootstrap 9).

I hope this answers some of your questions.

12 Likes

It looks like RHEL 9 was officially announced today at the Redhat Summit [ Red Hat Defines a New Epicenter for Innovation with Red Hat Enterprise Linux 9 ] with it be released in the ‘upcoming weeks’. This sounds like to time to start using the new build system to start building new images.

RHEL 9 was made General Availability [GA] yesterday. [annoucement Announcing the GA release of Red Hat Enterprise Linux 9.0 - Red Hat Customer Portal and release notes 9.0 Release Notes Red Hat Enterprise Linux 9 | Red Hat Customer Portal]. AlmaLinux was smart [Since they were preemptive in building+releasing a beta ahead of time and testing their build automation infrastructure] as they already said they would be releasing their final version next week.
Now

We are aware that it is GA. We saw the sources come in on Tuesday and we imported them and are slowly building what we can to get 9.0 to a point we can make usable repos and media.

Whether or not Alma produces betas is irrelevant - We did build a lot of the beta package set ourselves, so it is making it easier for us to actually build for our own 9.0 GA. While we wanted to provide the 9.0 beta, we hit too many snags and were not able to. And now that we have resolved a lot of the alt arch issues we were having with our new build system, we are striving to finish up the rest of the package set and tooling to produce a usable release candidate. If Alma releases 9.0 next week, good for them. If they need extra time to get things right, also good for them. They know what they’re doing as much as we know what we’re doing as well with the limited amount of volunteer time we have.

As I’ve explained to many others in the community, this isn’t a race nor a competition. Ours will be ready when it’s ready.

8 Likes

Lets look at numbers from Wikipedia’o CentOS page:

Version Delay (days)
5.0 28
6.0 242
7.0 27
8.0 140

If you did come from CentOS to Rocky, then you are used to waiting, aren’t you?
If you can’t wait, then you have always had the option to get RHEL.

In other words, Rocky had beta for 9, but not a public beta.

Overall, what would we do with public beta? Compare to our RHEL GA system and list where the beta lacks RHEL’s bugs, so Rocky’s team knows to add them?

1 Like

Those numbers are the old ways before streamlined automation and not how things are done now today. It looks like Alama Linux already has a complete 9.0 Iso. [ Index of /almalinux/9.0/isos/x86_64/ ]

Something tells me you didn’t actually read the numbers or if you did, you are misinterpreting them. If “streamlined automation” was actually the case, wouldn’t you think CentOS 8.0 would’ve been released in 27 days or less than their 7.0? It’s the same with Oracle. 43 days for 7.0, 72 days for 8.0.

3 Likes

IIRC, Red Hat revamped things for 8 compared to 7, so the “lets do like the previous version” was not a recipe for success.

@nazunalika It’s been two weeks. This seems to be the top google result for “RockyLinux 9” and searching the download site doesn’t provide any details. Every other result is a blog about what to expect or redit speculation.

Any chance we could get a status update on if you feel this is right around the corner? Or if this might end up being CentOS 5.3, or 6 and the changes will take weeks or months more? I think it would help add clarity to the topic for the community at large.

The front page of our website does have a small blurb when you scroll down on the progress of our work. You can also see the recent post from our twitter account here.

The packages we needed to build are completed. The build system is currently re-syncing repos, comps, dnf groups, and so on so that they can be properly exported. Once exported, initial images will be created for our testing team to evaluate.

Is there a way an external person like me can be part of testing/evaluation ?

1 Like

Anyone is welcome to join and help us evaluate! I would highly recommend joining us on mattermost and joining the testing channel. Alternatively, you can join the Rocky Linux space in Element/Matrix and join the testing channel there, or if you prefer IRC, login to libera and join #rockylinux-testing

The testing team has frequent meetings and plenty of discussions on testing criteria as well as discussions on OpenQA infrastructure.

I signed up to mattermost [chat.rockylinux.org] hoping to help test but when I tried to enter the chat, it says “Unable to create the new team membership because the team has reached the limit of members”

Hey Boris,

Thanks for pointing this out! I’ve adjusted the configuration to go past this limit that I didn’t know was set.

–Neil

HUMMMM You have to be YOUNG!! If you want to be “evaluate” a RH based distro join Fedora and you too can die on the “Bleeding Edge”. If you are not that Gung Ho, Join CentOS Streams – a little more stable, and you too can become another RH guinea pig (also known as a Beta Tester).

Truthfully I’m not quite sure why the rush to “test” 9.0. If I have leaned anything over the years is that ANY XYZ.0 release is so bug filled as to be totally useless. So what’s the difference if you have to wait a month or even a few months after the GA of ANY XYZ.0 release. One difference by waiting a little longer is that some of the really flagrant bugs will have been stomped out, that said, you will still have to carry a giant can of RAID with you… or be a full time entomologist who loves bugs!

You seem to miss the point here. The community wants to contribute to Rocky Linux. That is a Good Thing™. People want to help. Desire is that the Rocky 9 GA has as little bugs introduced by Rocky’s build procedure as possible. That is way better than to let others identify and fix all those bugs (the hard way, after GA).

Whether Rocky Linux is built from good or bad stuff is irrelevant. That is beyond our control here.

3 Likes

Hello! Please, tell me, is there any information when the release will be?

Please don’t rush the release, especially the UEFI and boot loader. Once the ISO is released it’s hard to change it.

1 Like