Bastidores do lançamento do Red Hat Enterprise Linux 10 (parte 4)

Esta série analisa as pessoas e o planejamento envolvidos na criação e no lançamento do Red Hat Enterprise Linux 10. Das primeiras etapas conceituais até o lançamento no Red Hat Summit 2025, ouviremos relatos em primeira mão de como o RHEL 10 surgiu.

Parte 1 | Parte 2 | Parte 3

No post anterior sobre como o Red Hat Enterprise Linux (RHEL) 10 surgiu, conhecemos o processo de teste e como as principais funcionalidades (e as histórias em torno delas) começaram a se integrar. Na parte 4, essas histórias ganham mais foco enquanto a equipe trabalha para dar os retoques finais em várias funcionalidades antes do code freeze.

2025 (seis meses para o Summit 2025)

Brian Stinson, Engenheiro de Software Principal

"A reta final: Essa parte é onde as coisas ficam um pouco mais intensas para as equipes individuais, porque não se trata apenas de 'estamos finalizando as funcionalidades?', mas de 'conseguimos concluir o restante dos ajustes de preparação essenciais para o lançamento?' Todos os meus pacotes foram incluídos? Concluímos o QE no cronograma? Eles foram enviados para feedback? Essas atividades aumentam bastante à medida que avançamos para o code freeze."

Chris Wells, Diretor Sênior de Marketing de Produto – Unidade de Negócios RHEL

"Eu sabia que precisávamos pegar essa história e tentar torná-la empolgante. Mas não mudaríamos as funcionalidades desta versão; apenas mudaríamos a forma como falaríamos sobre elas.

Então, tive uma reunião em Columbus com Marty Loveless, Gerente Sênior de Marketing de Produto do RHEL 10, e Scott McCarty, que mora a apenas uma ou duas horas de distância, em Akron. Ele dirigiu para nos encontrar. Nós nos trancamos em uma sala de conferências e fizemos um brainstorm sobre os diferentes ângulos pelos quais poderíamos abordar o assunto. Tentamos olhar para algo novo e descobrir: "Havia um ângulo diferente?"

Major Hayden, Engenheiro de Software Sênior Principal

"Eu e outro colega da Red Hat trabalhamos na engenharia para criar o código, então dividimos o trabalho. RAG [Retrieval Augmented Generation] era nosso principal desafio. Presumimos que era assim: você coloca vários PDFs em um bucket e pronto, vamos pesquisar. Isso não estava certo.

Grande parte desse desafio surgiu por ser a primeira vez que muitos de nós lidamos com vetores. Aprendi cálculo na escola, então sei que vetores são uma linha em um plano cartesiano, mas é basicamente isso. Como essas frases se tornam vetores? Isso não faz sentido. Então, um dia, precisei parar e reaprender um pouco de cálculo para entender o que isso realmente está fazendo.

O maior obstáculo que enfrentamos foi não obter resultados de qualidade. 

Lemos um post em um blog ou um artigo em que alguém sugeria solicitar ao LLM para refinar a pergunta do cliente. Acabamos criando este processo de refinamento de perguntas: recebemos a pergunta do cliente, enviamos para um LLM e dizemos: "Esta pergunta provavelmente é sobre o RHEL, sobre produtos Red Hat ou sobre Linux". Você pode usar essa pergunta do cliente e transformá-la em cinco perguntas mais específicas com palavras-chave alinhadas a esses tópicos? Um cliente pode dizer algo como "SSH sem reiniciar". O refinamento tornaria as perguntas mais específicas e usaria frases com maior probabilidade de aparecer em nosso conteúdo de RAG. Assim, a pesquisa vetorial corresponderia a mais documentos. De repente, percebemos que começamos a ter resultados melhores."

Wells

"Poder utilizar o que considero o diferencial exclusivo da Red Hat no mercado — todo o nosso conhecimento e experiência em Linux para RHEL — e transformar isso em produto para oferecer como um assistente via Lightspeed. Isso nos deu uma maneira muito poderosa de falar sobre o RHEL 10."

Stef Walter, Senior Director, Linux Engineering

"Nossos clientes em geral — e estamos falando de grandes empresas — estavam implantando o image mode antes mesmo do suporte oficial. Eles diziam: 'Isso é tão bom que não nos importamos'. Estamos implantando agora'."

A ficha caiu quando veio a surpresa: 'Uau, eles estão implantando em produção e não estão esperando por nós'. Isso é tão valioso para o processo de TI e para a mudança que eles tentam fazer que eles não vão esperar por nós. E agora temos que acompanhar o ritmo."

Wells

"Tivemos uma história muito poderosa sobre o image mode. E dissemos: 'E se falarmos sobre o image mode como uma maneira diferente de aplicar patches e atualizar seus sistemas?' No último ano, falamos sobre o image mode mais como uma forma de implantar novos sistemas, novas imagens e implantações na edge. O que é perfeitamente válido e bom. 

Mas pensamos: 'E se fôssemos um passo além? E se, em vez de apenas implantar na edge, você literalmente criasse uma imagem de um servidor de produção, a tornasse imutável e a implantasse dessa forma?' Sempre que você precisasse atualizar esse servidor, bastaria atualizar a imagem e, essencialmente, reinstalar a imagem do sistema. Essa seria uma maneira diferente de implantar. Ao fazer isso, você eliminaria uma das principais dores de cabeça do gerenciamento de sistemas Linux: a aplicação de patches. Realizar o gerenciamento de patches por meio do image mode seria muito mais fácil, rápido e apresentaria muito menos riscos do que o método tradicional de pacotes.

Estamos quase no ponto de lançamento do Red Hat Enterprise Linux 10 no Summit 2025. Essa é a parte fácil, certo? Certo? Acompanhe o próximo post em 2026, quando o time explicará os mecanismos e processos reais de lançamento.