More than meets the eye: Behind the scenes of Red Hat Enterprise Linux 10 (Part 4)

This series takes a look at the people and planning that went into building and releasing Red Hat Enterprise Linux 10. From the earliest conceptual stages to the launch at Red Hat Summit 2025, we’ll hear firsthand accounts of how RHEL 10 came into being.

Part 1 | Part 2 | Part 3

In our previous installment of the story of how Red Hat Enterprise Linux (RHEL) 10 came to be, we got insights into the testing process and how the headline features (and the stories around those features) started coming together. In part 4, those stories come into clearer focus as the team works to put the finishing touches on various features before code freeze.

2025 (6 months until Summit 2025)

Brian Stinson, principal software engineer

"The last stretch of time: That part is actually where things get a little bit more intense for the individual teams because it’s not only ‘Are we buttoning up features?’ but ‘Were we able to cover the rest of the baseline enablement stuff we needed to do as part of the release?’ Are all my packages in? Did we get them QE’d on the right schedule? Have they gone out for feedback? Those types of activities actually ramp up quite a bit as we head toward code freeze."

Chris Wells, senior director, Product Marketing - RHEL Business Unit

"I knew we needed to take this story and try and make it exciting. But we weren't going to change what features were in this release, we could only change how we could talk about those features.

So I had a meeting here in Columbus where I pulled in Marty Loveless, who was the lead product marketing manager on RHEL 10, and Scott McCarty, who lives just an hour or two up the road in Akron. He drove down for the day. We locked ourselves in a conference room, and we just brainstormed ‘what were the different angles we could talk about things in?’ Trying to look at something that was new and figure out: Was there a different angle?"

Major Hayden, senior principal software engineer

"It was another Red Hatter and I on the engineering side building the code, so he and I divided the work. RAG [retrieval augmented generation] was our number one challenge. We kind of assumed that it was: You throw a bunch of PDFs in a bucket, boom, let’s search. That was not correct.

A lot of the challenge there stemmed from: It was the first time a lot of us had ever dealt with vectors. Like, I took calculus back in school, so I know vectors are a line on a Cartesian plane, but that’s about it. How are these sentences becoming vectors? It doesn’t make any sense. So I actually had to sit down one day and go back and relearn some calculus to figure out, ‘what is this really doing?’

Then the biggest roadblock we hit up was we just weren’t getting quality results. 

But we read a blog post or some article where someone said to ask the LLM to refine the customer’s question. We eventually created this question refinement process where we get the question from the customer and then we send it to an LLM, and we say, ‘Hey, this question is very likely about RHEL or it’s about Red Hat products or it’s about Linux. Can you take this question from the customer and change it into 5 more specific questions with keywords that line up with these topics?’ So a customer might say, like, ‘SSH no restart.’ Then the question refinement would make the questions more specific and use phrases that are more likely to appear inside of our RAG content. Then the vector search would match with more documents. All of a sudden we started seeing we were getting better results back."

Wells

"Really being able to take what I think is the unique differentiator for Red Hat in the marketplace—all of our knowledge and expertise around Linux for RHEL—and be able to productize and provide that as an assistant to someone via Lightspeed. That gave us a really powerful way to talk about RHEL 10."

Stef Walter, senior director, Linux Engineering

"Our customers across the board—and we’re talking big name customers—were deploying image mode before it was supported. They were like, ‘This is so great, we don’t care. We’re deploying it now.’

When it really started to hit home was the surprise of, ‘Oh wow, they’re deploying it in production and they’re not waiting for us.’ This is so valuable to them in their IT process and the change that they are trying to make, that they’re not going to wait for us. And now we’ve got to keep up."

Wells

"We had this really powerful story around image mode. And we said, ‘Well, what if we talk about image mode as a different way to patch and update your systems?’ We had been talking about image mode over the last year more as a way you deploy new systems and new images and edge deployments. Which is all perfectly valid, all good. 

But we said, ‘Well, what if we took it one step further? What if instead of just deploying this to the edge, what if you literally created an image of a production server, made it immutable, and deployed it that way?’ So whenever you needed to do an update to that server, you would just update the image and essentially reimage the system. It would be a different way to deploy. And if you did that, it would take away one of the huge headaches of managing Linux systems, which is going through and patching them. Because if you did the patch management through image mode, it would be a lot easier, a lot quicker, a lot less risk than doing it the traditional package way of doing things."

We're now almost at the point of RHEL 10 launching at Summit 2026 - that's the easy part, right? ...right?! Look for the next post in 2026 as the team walks us through the actual launch mechanisms and processes.