Temos uma política bastante restritiva em relação a anúncios no site. Eles nunca irão te atrapalhar!
Além disso, usamos banners para lhe informar de assuntos importantes. Os bloqueadores de anúncios impedem que esses banners sejam visualizados.
Sendo assim, para continuar, é importante que você desligue o bloqueador de anúncio e recarregue a página. Obrigado!

9 de outubro de 2026 · Alexey Kovyazin, Firebird Foundation
Traduzido por IA. Artigo original aqui.

Em resumo

O Firebird está arrecadando fundos para reformular seu controle de qualidade (QA). O fluxo de alterações no código cresce mais rápido do que a capacidade do projeto de verificá-lo. Sem novos recursos, a qualidade dos lançamentos (releases) será prejudicada.

O Firebird é um banco de dados relacional de código aberto. Sua comunidade o desenvolve e o utiliza. O projeto estima que cerca de um milhão de desenvolvedores de software utilizem o Firebird em suas aplicações. Quatro branches são suportadas simultaneamente: 3.0, 4.0, 5.0 e 6.0 (em desenvolvimento). Cada correção de bug e cada melhoria precisa passar por verificações manuais e automatizadas antes do lançamento.

Em 2025, o repositório do Firebird recebeu 190 pull requests (PRs). Isso é 3,1 vezes mais do que em 2020, e 2026 já está à frente de 2025. As ferramentas de IA são um grande motivo: escrever código ficou mais barato, mas verificá-lo não. A complexidade também aumenta. O Firebird 6.0 está em desenvolvimento e, no primeiro semestre de 2026, houve quase o dobro de PRs com mais de 200 linhas em comparação com o ano anterior: 40 contra 21.

A ideia principal da reforma é executar o QA com mais frequência. Hoje, a suíte de testes roda uma vez por dia e apenas após o merge. Para PRs, ela sequer é executada. Após a reforma, todo PR aprovado passará por um subconjunto obrigatório de QA antes do merge, a cada atualização. PRs grandes também passarão pela suíte completa e por um teste de desempenho.

Para isso, precisamos de engenheiros de QA, máquinas em nuvem, um agente de IA para a primeira análise de PRs e novos testes. Pedimos aos usuários do Firebird e às empresas cujos negócios dependem do Firebird que apoiem a reforma. O primeiro passo já foi dado: em 8 de outubro de 2026, a Firebird Foundation iniciou uma campanha de financiamento coletivo (crowdfunding) para arrecadar US$ 20.000 para o QA.

O Firebird em números

O Firebird é desenvolvido como um projeto de código aberto há 26 anos. Hoje ele conta com quatro branches, 12 plataformas na release 5.0.4 e cerca de 763 mil linhas de código. Uma suíte de 3.138 testes automatizados verifica esse código.

Contamos o código com a ferramenta cloc no diretório src da release 5.0.4, sem linhas em branco e sem comentários. Cerca de 288 mil das 763 mil linhas são tabelas de conjuntos de caracteres nacionais. O código C/C++ do motor (engine), da camada SQL, da camada de rede e dos utilitários tem cerca de 453 mil linhas. As plataformas foram obtidas dos arquivos da release 5.0.4 de 17 de abril de 2026: Windows (x86, x64), Linux (x86, x64, ARM32, ARM64), macOS (x64, ARM64) e Android (x86, x64, ARM32, ARM64).

O fluxo de alterações está crescendo

Desde 2020, o número de pull requests no Firebird cresceu 3,1 vezes. Nos primeiros nove meses de 2026, houve quase tantos PRs quanto em todo o ano de 2025: 184 contra 190.

Além dos PRs, o tracker recebe relatos de bugs e solicitações de recursos (feature requests). Em 9 de outubro de 2026, cerca de 1.800 issues e 92 PRs estavam abertos. O número de autores também cresce: 19 pessoas abriram PRs em 2020, 30 em 2025 e já são 32 em 2026. Todo relato de bug precisa ser reproduzido. Todo PR precisa ser verificado e testado em sua própria branch e nas branches para as quais a correção é portada (backported).

Os relatos de bugs chegam em um ritmo estável: de 235 a 368 por ano, sem crescimento claro. O que cresce é o fluxo de alterações de código: em 2026, os PRs ultrapassaram as issues pela primeira vez, 184 contra 173 até 9 de outubro. Juntos, são cerca de 440 itens de trabalho por ano, e cada um deles precisa ser verificado.

Como o QA funciona hoje

Hoje o QA roda apenas após o merge. O CI no GitHub compila o código, mas não o testa. A suíte de testes roda uma vez por dia em servidores fornecidos pela IBSurgeon, e somente para as branches que tiveram commits. Pessoas fazem a revisão, as verificações e a análise dos resultados, e essas etapas não escalam com o fluxo de alterações.

• CI no GitHub: apenas compilação. Cada push e cada PR é compilado no GitHub Actions: são 22–23 jobs de build para Linux (x64, x86, ARM, Alpine), Windows (x64, x86, ARM64), macOS e Android. A suíte de testes não faz parte do CI. Para cada push, ela levaria horas de tempo de máquina, e o GitHub oferece a um projeto gratuito no máximo 20 jobs paralelos para toda a organização. O projeto já atinge esse limite: em 7 de outubro de 2026, 7 PRs foram abertos ao mesmo tempo, e as builds aguardaram na fila por até 4 horas. Os testes só podem ser iniciados no Actions manualmente e apenas no Linux x64.
• Revisão. Os desenvolvedores principais leem a alteração, discutem-na no PR e pedem atualizações quando necessário. Muitas vezes, uma correção precisa ser portada para várias branches, e cada branch deve ser verificada separadamente.
• Verificação manual. Um engenheiro de QA primeiro reproduz o bug em um snapshot compilado antes da correção. Em seguida, o engenheiro confirma que o bug desapareceu em um snapshot com a correção. O teste só é publicado após isso. A seção “O dia a dia do QA” abaixo descreve esse processo em detalhes. Mais de 1.500 arquivos de teste possuem uma nota “Checked on” com os números das builds verificadas.
• A suíte de testes firebird-qa. Trata-se de um plugin pytest e 3.138 testes. Deles, 1.962 são testes de regressão, e cada um está vinculado a um bug específico (1.481 arquivos para bugs do antigo tracker CORE e 481 para bugs do GitHub). Outros 1.176 são testes funcionais: SQL, triggers, domains, replicação, transações. O repositório possui 3.901 commits.
• Execuções noturnas (nightly runs): apenas para branches alteradas. O QA roda separadamente do CI, em servidores fornecidos pela IBSurgeon: uma vez por dia, no Windows e no Linux, e somente para as branches que tiveram commits durante o dia. Para cada versão, a suíte roda duas vezes: em duas arquiteturas de servidor, SuperServer e Classic. As builds do HQbird são verificadas da mesma maneira. No firebirdtest.com, cada resultado é comparado com as 35 execuções anteriores: novas falhas, crashes com dumps e stack traces, e testes que ficaram mais lentos.
• Desempenho. O OLTP-EMUL emula uma carga de trabalho OLTP real (pedidos, faturas, reservas de peças) em dezenas de sessões paralelas. Ele mede o número de operações de negócios bem-sucedidas por minuto. Uma medição leva cerca de uma hora. Os resultados mais recentes publicados no firebirdtest.com são de 20 de abril de 2026 e ainda não incluem a branch 6.0.

A regra é a mesma para todas as branches: se houve alteração, há execução de QA. Branches mais antigas mudam com menos frequência, por isso têm menos execuções. O tempo de execução cresce mais rápido do que o número de testes:

Branch	Testes	Execução, Linux	Execução, Windows	Execuções em 30 dias, Linux / Windows
6.0 (master)	≈3.090	4 h 39 min	2 h 28 min	13 / 7
5.0	≈2.880	2 h 30 min	1 h 41 min	11 / 7
4.0	≈2.690	2 h 19 min	1 h 35 min	6 / 8
3.0	≈2.230	1 h 31 min	52 min	4 / 4

O tempo de execução é a mediana das últimas 35 execuções no firebirdtest.com em 9 de outubro de 2026. É a soma de duas execuções, nos modos SuperServer e Classic. “Testes” é o número de testes executados para essa branch. Todas as branches utilizam as mesmas máquinas: o servidor Linux tem 2 CPUs e 7 GB, e o servidor Windows tem 8 CPUs e 127 GB. A branch 6.0 tem 7% mais testes do que a 5.0, mas sua execução no Linux leva 86% mais tempo. O tempo depende não apenas da quantidade de testes, mas também do que esses testes fazem.

Hoje o QA não roda para PRs de forma alguma. Uma regressão só se torna visível na manhã seguinte ao merge, juntamente com todos os commits daquele dia. Depois, alguém ainda precisa descobrir exatamente qual alteração a causou.

O dia a dia do QA: como uma correção é verificada

Verificar uma correção é uma pequena investigação. Um teste só é publicado se o engenheiro de QA tiver capturado o bug em uma build anterior à correção e confirmado que o bug desapareceu em uma build com a correção.

Passo a passo:

• Rascunho do teste. Copiamos o cenário .sql do tracker ou escrevemos um rascunho de teste em pytest.
• Snapshot antes da correção. Encontramos, ou compilamos nós mesmos, um snapshot do momento mais próximo ao push da correção, porém anterior a ele.
• Reprodução. Executamos o cenário do tracker com o rascunho do teste e confirmamos que o bug existia naquele momento. Se o bug não se reproduzir, geralmente há três motivos:
  • o bug desapareceu antes, por causa de um commit anterior sobre este tema ou até mesmo sobre outro tema;
  • a reprodução depende de algo que o ticket não descreve: um parâmetro de configuração, o sistema operacional ou, menos frequentemente, o tipo de build (debug ou release);
  • o script de verificação no tracker é muito “fraco”; isso é raro, mas acontece;
  em qualquer um desses casos, não prosseguimos até reproduzirmos o bug nós mesmos. Tentamos um snapshot de uma data ainda mais antiga, o dia em que o ticket foi criado. Se chegarmos a um beco sem saída, pedimos orientação a um desenvolvedor principal.
• Snapshot com a correção. Encontramos ou compilamos um snapshot a partir dos fontes correspondentes ao SHA do commit da correção. Se esse push tiver sido o único naquele dia, o snapshot pronto compilado automaticamente com a mensagem “Increment build number” já é suficiente.
• Verificação da correção. Confirmamos que o bug desapareceu nesse snapshot. Se desapareceu, limpamos o rascunho do teste e o publicamos: git add, git commit, git push. Se o bug ainda estiver lá, reverificamos nosso teste várias vezes. Se o problema for confirmado, alertamos os desenvolvedores principais.

Regras para os testes:

• Um push, um teste. Essa é a prática aceita. A exceção é uma alteração em grupo de algo pequeno em muitos testes de uma só vez.
• Um arquivo .py, uma função de teste como def test_N(...). Outras funções no arquivo, exceto as internas, não devem se chamar test_*. Esse é um requisito estrito: o processamento dos logs do pytest e o esquema do banco de dados que armazena os resultados de todas as execuções dependem disso.

Cada etapa consome tempo de engenharia e, muitas vezes, uma compilação de snapshot separada. Portanto, o gargalo não é escrever código, mas verificá-lo. É exatamente aí que a reforma adiciona pessoas e máquinas em nuvem.

O que mudou: mais código do que pessoas para verificá-lo

As ferramentas de IA tornaram a escrita de código e de relatos de bugs muito mais barata, mas não tornaram a verificação mais barata. Para um motor de banco de dados, isso é especialmente perigoso. Um patch que parece correto pode quebrar a concorrência, a recuperação de falhas (crash recovery) ou o desempenho, e isso só aparecerá sob carga ou em outra plataforma.

A tendência é comum a todo o software de código aberto:

• De acordo com o GitHub Octoverse 2025, o número de pull requests criados no GitHub cresceu 20% em um ano, e o de pull requests mesclados (merged) cresceu 23%. O GitHub associa esse crescimento ao lançamento do agente de codificação do Copilot e à revisão automática de código.
• O projeto curl encerrou seu programa de recompensas por bugs (bug bounty) em 1º de fevereiro de 2026, devido a uma enxurrada de relatos de baixa qualidade, frequentemente gerados por IA.
• Em fevereiro de 2026, os mantenedores do Godot pediram financiamento publicamente para contratar mais pessoas a fim de processar PRs gerados por IA. Nos mesmos dias, o GitHub começou a discutir ferramentas para filtrar esses PRs.

O fluxo no Firebird cresceu da mesma forma: 134 PRs em 2024, 190 em 2025 (+42%) e 184 até 9 de outubro de 2026, o que representa cerca de 238 no ritmo anual. Damos as boas-vindas a novos colaboradores e não queremos limitar as contribuições. O objetivo é escalar a verificação, não fechar a porta.

Mas a complexidade importa mais do que os números. O Firebird 6.0 está em desenvolvimento, e cada vez mais PRs trazem recursos de grande porte. No primeiro semestre de 2025, 21 de 104 PRs tinham mais de 200 linhas; no primeiro semestre de 2026, foram 40 de 106. O número total de PRs quase não mudou, mas a fatia de PRs grandes cresceu de 20% para 38%.

Alterações desse tipo exigem verificações em vários níveis: testes funcionais no Linux e no Windows em ambos os modos de servidor, desempenho sob carga e portabilidade para outras branches. E não apenas uma vez: um PR grande é atualizado após os comentários de revisão, e PRs com mais de 1.000 linhas têm, em média, cerca de oito iterações desse tipo. Cada iteração precisa ser verificada novamente.

Reforma do QA: verificar com mais frequência e antes do merge

A ideia principal da reforma é executar o QA com mais frequência: não uma vez por dia após o merge, mas para cada PR aprovado antes do merge, em cada atualização. A segunda parte consiste em mais testes, incluindo um subconjunto obrigatório e rápido de QA para PRs.

Todas as quatro direções se apoiam no que já funciona: a suíte de testes, as execuções noturnas nos servidores da IBSurgeon e o CI. As execuções noturnas permanecem: commits diretos dos desenvolvedores principais também passam por elas e, na branch master, eles representam cerca de três quartos de todas as alterações.

Direção	O que fazemos	O que muda
Mais engenheiros de QA	Reproduzem relatos de bugs, analisam os resultados das execuções de PRs e das execuções noturnas, escrevem testes e montam o subconjunto obrigatório de QA	Todo PR aprovado e relato de bug é verificado em um tempo previsível; os desenvolvedores principais gastam menos tempo longe do desenvolvimento
QA para PRs na nuvem	VMs de curta duração na DigitalOcean (Linux) e no Azure (Windows): o subconjunto obrigatório para cada push de um PR aprovado; a suíte completa e o OLTP-EMUL antes do merge de PRs grandes	Uma regressão fica visível no próprio PR, antes do merge; os servidores noturnos não ficam sobrecarregados
Agente de IA para primeira análise	Para um novo PR, verifica se é uma duplicata e se o problema está confirmado, estima o tamanho e os riscos, sugere o escopo de testes e escreve uma recomendação	Uma pessoa decide em minutos se libera o PR para o QA ou se o rejeita; PRs descartáveis (junk PRs) são filtrados antes de qualquer execução
Cobertura e subconjunto obrigatório	Escrevemos testes para áreas com baixa cobertura, medimos a cobertura de código e selecionamos testes para o subconjunto obrigatório: no máximo uma hora por sistema operacional	Uma verificação rápida a cada push e menos regressões nos lançamentos

Alguns detalhes sobre cada direção:

• Engenheiros de QA. Hoje a verificação depende de um grupo muito pequeno de pessoas; a reforma paga uma bolsa (grant) para um engenheiro de QA em meio período. As execuções de PRs adicionarão cerca de 140 resultados por mês aos 60 noturnos, e alguém precisa analisar cada falha.
• Nuvem. Os servidores noturnos já estão ocupados: se todas as branches tiverem commits, a suíte completa leva 11 horas no Linux e 6,6 horas no Windows. Os PRs precisam de máquinas separadas que iniciam em paralelo e são excluídas após a execução, pagando apenas pelo tempo em que funcionam.
• Agente de IA. Ele não substitui o revisor e não aprova PRs sozinho. Sua tarefa é preparar a decisão: uma pessoa vê um resumo pronto e gasta minutos, não uma hora.
• Subconjunto obrigatório e cobertura. O subconjunto obrigatório é selecionado por tempo, não pelo número de testes: alguns testes pesados podem levar mais tempo do que uma centena de testes leves. A meta é de no máximo uma hora por sistema operacional, e a própria seleção é um trabalho à parte para os engenheiros de QA. Além disso, algumas áreas têm cobertura fraca: por exemplo, há 6 testes para BLOB, 4 para monitoramento e 2 para serviços (services).

Como o caminho de um PR muda após a reforma: a análise e a aprovação vêm antes do QA, e os testes passam para o momento anterior ao merge.

A campanha de financiamento coletivo da Firebird Foundation de US$ 20.000 foi anunciada para custear o tempo dos engenheiros de QA e as máquinas virtuais. O dinheiro arrecadado também paga pelo agente de primeira análise e pela configuração do QA para PRs.

Como um PR entra no QA

Uma execução de QA só começa depois que uma pessoa a aprova. A execução roda o código do PR em nossas máquinas, portanto o PR precisa ser revisado primeiro. Ele pode ser rejeitado imediatamente como duplicata, sem sentido, problema não confirmado ou alteração intencionalmente destrutiva.

1. PR aberto. O CI o compila, como hoje. Um PR de um novo colaborador sequer inicia o CI até que um mantenedor o aprove. Essa é a configuração padrão do GitHub, e também protege contra a geração em massa de PRs descartáveis.
2. Primeira análise. O agente de IA lê o PR e a issue vinculada e escreve uma recomendação no PR: liberá-lo para o QA ou rejeitá-lo, qual classe de complexidade o PR possui e quais testes são necessários.
3. Aprovação. Um desenvolvedor principal ou um engenheiro de QA aprova ou rejeita o PR. Uma pessoa sempre toma a decisão.
4. QA a cada push. Após a aprovação, cada push passa automaticamente pelo subconjunto obrigatório de QA no Linux e no Windows. Cada execução utiliza uma VM de curta duração sem acesso aos segredos (secrets) do projeto.
5. Antes do merge. PRs grandes passam pela suíte completa, e os maiores também passam pelo OLTP-EMUL em comparação com a build base.
6. Após o merge. A execução noturna, como hoje.

Como funcionam as execuções em paralelo

Na nuvem, quatro VMs em paralelo custam o mesmo que uma máquina em sequência. Mas o resultado fica pronto quando a branch mais longa termina: após 4 h 39 min em vez de 11 horas.

Considere a execução noturna da suíte completa no Linux para todas as quatro branches: a 3.0 leva 1 h 31 min, a 4.0 leva 2 h 19 min, a 5.0 leva 2 h 30 min e a 6.0 leva 4 h 39 min. Em um único servidor, são 11 horas seguidas; em quatro VMs, são 4 h 39 min. A nuvem cobra pelo tempo real de trabalho, portanto em ambos os casos pagamos pelas mesmas 11 máquinas-hora.

Os PRs funcionam da mesma maneira: a suíte completa no Linux e no Windows e duas medições do OLTP-EMUL rodam ao mesmo tempo, e um PR grande recebe uma resposta em cerca de 5 horas, não em 11.

Linux: DigitalOcean, droplet de 16 GB

Desde 1º de janeiro de 2026, a DigitalOcean cobra pelos droplets por segundo, com um mínimo de 60 segundos, de modo que pagamos exatamente pelo tempo de execução. Os preços são da página de preços da DigitalOcean em 9 de outubro de 2026.

Droplet de 16 GB	vCPU	Preço, US$/h	Suíte 6.0 completa, 4 h 39 min	Todas as 4 branches, 10,98 máquinas-hora
Basic	8 compartilhadas	0,143	US$ 0,66	US$ 1,57
General Purpose	4 dedicadas	0,1875	US$ 0,87	US$ 2,06
CPU-Optimized	8 dedicadas	0,25	US$ 1,16	US$ 2,75

Para os testes de desempenho, utilizamos General Purpose: núcleos dedicados não são compartilhados com vizinhos no servidor, tornando as medições repetíveis. Suíte 6.0 completa no Linux: US$ 0,1875/h × 4,65 h ≈ US$ 0,87. O servidor Linux da IBSurgeon é mais fraco (2 CPUs e 7 GB), então na nuvem a execução provavelmente será mais rápida; em nossos cálculos, usamos o tempo medido atual como base.

Windows: Azure, VM D4s v5 (4 vCPU, 16 GB)

A DigitalOcean não oferece droplets Windows, então as execuções em Windows vão para o Azure. Os preços são para a região West Europe (Europa Ocidental), no modelo pague pelo uso (pay-as-you-go), obtidos da API de Preços de Varejo do Azure em 9 de outubro de 2026. A licença do Windows está incluída no preço; discos e tráfego não estão incluídos.

VM D4s v5, 16 GB	Preço, US$/h	Suíte 6.0 completa, 2 h 28 min	Todas as 4 branches, 6,6 máquinas-hora
Windows, regular	0,414	US$ 1,02	US$ 2,73
Windows, Spot	0,0765	US$ 0,19	US$ 0,50
Linux, regular (para comparação)	0,23	US$ 0,57	US$ 1,52

Suíte 6.0 completa no Windows: US$ 0,414/h × 2,47 h ≈ US$ 1,02. O servidor Windows da IBSurgeon é mais potente do que a VM na nuvem (8 CPUs e 127 GB), portanto na nuvem a execução pode levar mais tempo; a reserva para execuções repetidas cobre essa diferença. As VMs Spot são mais de cinco vezes mais baratas, mas o Azure pode retomá-las a qualquer momento. Elas servem bem para testes funcionais, mas não para medições de desempenho.

Quanto custa o QA para PRs por seis meses

O QA para cada PR aprovado custará cerca de US$ 477 por seis meses. Isso consome 2,8 vezes menos tempo de máquina do que rodar a suíte completa com OLTP-EMUL a cada push. A economia vem do subconjunto obrigatório e do fator de complexidade.

A previsão é de 127 PRs nos próximos seis meses: foram 114 PRs nos últimos seis meses com crescimento de 25% ao ano, a média desde 2020: 114 × 1,25^0,5 ≈ 127. As issues não entram nas execuções em nuvem: um engenheiro de QA reproduz um relato de bug em snapshots, e a correção chega como um PR ou um commit.

Existem três tipos de execução. Todos são calculados para a branch 6.0, para onde vai a maioria dos PRs e onde a suíte é mais longa. Adicionamos 15 minutos de preparação a cada inicialização de VM:

• Subconjunto obrigatório: 1 h no Linux e 1 h no Windows: 2,5 máquinas-hora, US$ 0,75.
• Suíte completa: duas execuções, SuperServer e Classic, somando 4 h 39 min no Linux e 2 h 28 min no Windows: 7,6 máquinas-hora, US$ 2,04.
• OLTP-EMUL: a build do PR e a build base em paralelo, 1,5 h cada no Linux: 3,5 máquinas-hora, US$ 0,66.

O que executar e quantas vezes depende do PR. Um PR de 5 linhas e um PR de 5.000 linhas diferem tanto no número de atualizações quanto na profundidade das verificações. Por isso, usamos um fator de complexidade: o tempo de máquina por PR comparado com a classe mais simples.

Classe do PR, linhas alteradas	Fatia de PRs	Pushes por PR	O que executamos	Máquinas-hora por PR	Fator
S, até 20	42%	1,5	subconjunto obrigatório a cada push	3,8	1
M, 21–200	24%	2	subconjunto obrigatório a cada push	5,0	1,3
L, 201–1.000	22%	3	o mesmo + suíte completa antes do merge	15,1	4
XL, mais de 1.000	12%	8	o mesmo + 2 suítes completas e OLTP-EMUL	38,7	10

As fatias por classe e a contagem de pushes vêm de 214 PRs dos últimos 12 meses. Estimamos os pushes pelo número de dias com novos commits em um PR: em média 1,2, 1,6, 2,1 e 8,0 por classe. Esse é um limite inferior, pois o force-push oculta algumas iterações, de modo que os valores na tabela foram arredondados para cima.

Dos 127 PRs previstos, 53 estão na classe S, 30 na M, 28 na L e 16 na XL. Um PR custa US$ 1,13, US$ 1,50, US$ 4,30 e US$ 10,76 por classe. Adicionamos outros 20% para execuções repetidas devido a testes instáveis e falhas de VM.

(53 × US$ 1,13 + 30 × US$ 1,50 + 28 × US$ 4,30 + 16 × US$ 10,76) × 1,2 ≈ US$ 477

Compare isso com o cenário atual e com a opção “tudo a cada push”:

Cenário	Tempo de máquina por mês	Total vs. hoje	Nuvem por 6 meses
Hoje: execuções noturnas das branches alteradas nos servidores IBSurgeon	153 máquinas-hora	1×	—
Reforma: subconjunto obrigatório a cada push, suíte completa por classe de PR	+232 máquinas-hora	2,5×	US$ 477
Suíte completa e OLTP-EMUL a cada push de cada PR	+651 máquinas-hora	5,3×	US$ 1.139

O tempo de máquina atual é calculado com base nos últimos 30 dias: 34 execuções no Linux e 26 no Windows. Em ambos os cenários, o custo financeiro é pequeno. O tempo de espera importa mais: com o subconjunto obrigatório, o autor recebe uma resposta para cada atualização em cerca de 1 hora e 15 minutos; com a suíte completa, somente após 5 horas.

Se os PRs crescerem mais rápido do que o previsto, no ritmo de 2025 de +42% ao ano, haverá cerca de 136 deles, e as execuções custarão cerca de US$ 511. A reserva cobre a diferença.

Expansão de testes para a 6.0 e maior intensidade de testes

Preparar o lançamento da versão 6.0 e executar testes de forma mais intensiva adicionará cerca de US$ 150 às execuções em nuvem por seis meses, cerca de 30% a mais sobre o QA para PRs. O principal custo da expansão não são as máquinas, mas o tempo dos engenheiros de QA para criar novos testes.

De acordo com o roadmap do Firebird 6, a versão alpha chega no 4º trimestre de 2026, a beta no 2º trimestre de 2027 e o lançamento final no 4º trimestre de 2027. A suíte cresce com elas: os testes que rodam exclusivamente na 6.0 cresceram de 93 para 225 em um ano; 91 deles foram adicionados nos últimos seis meses e 49 no último trimestre. Novos recursos (schemas, tablespaces, funções JSON, o tipo ROW, o cache de metadados compartilhado) exigem testes novos e muitas vezes pesados.

O que é adicionado	O que planejamos	Máquinas-hora por 6 meses	Nuvem por 6 meses
Mais PRs e mais PRs grandes	após o alpha, 15% mais PRs: 146 em vez de 127; 38% dos PRs têm mais de 200 linhas, como no primeiro semestre de 2026	207	US$ 72
Verificações das builds alpha e beta	6 builds; para cada uma: suíte completa no Linux, Windows x64 e Windows x86, OLTP-EMUL 6.0 vs. 5.0 e um teste de estresse de 24 horas no Linux	234	US$ 62
Crescimento da suíte 6.0	até abril de 2027 a suíte completa ficará 20% mais longa; em média 10% mais longa no período	51	US$ 16
Total		492	US$ 150

As máquinas-hora são exibidas sem repetições; o custo inclui a reserva de 20% para execuções repetidas, conforme explicado acima.

Com a expansão, o tempo de máquina cresce cerca de três vezes em comparação com hoje: 153 máquinas-hora de execuções noturnas, 232 para o QA de PRs e outras 82 para a expansão, totalizando cerca de 467 por mês. Os servidores noturnos não têm essa capacidade. E, após o beta, surgirá uma branch 6.0 separada, passando a existir cinco execuções noturnas em vez de quatro.

A principal expansão é o trabalho humano. Se o ritmo do último trimestre continuar, cerca de 100 testes exclusivos para a 6.0 serão adicionados em seis meses, e ainda mais com o alpha e os relatos de bugs dos testadores. Cada um desses testes percorre o caminho descrito em “O dia a dia do QA”. A bolsa do engenheiro de QA remunera esse trabalho. Se houver mais testes, o restante do valor arrecadado e a reserva poderão pagar por mais horas de QA.

Orçamento para seis meses

Seis meses da reforma custam cerca de US$ 18.402, o que representa US$ 1.598 a menos do que a meta de financiamento coletivo de US$ 20.000. O restante pode permanecer na reserva para o crescimento de PRs ou pagar por mais horas de QA. Cerca de 83% do dinheiro vai para o trabalho de pessoas; a nuvem e o agente de IA juntos custam cerca de 7%.

Item	Como é calculado	Por mês	Por 6 meses
Bolsa para engenheiro de QA, meio período	plano do projeto	US$ 2.133	US$ 12.798
Configuração do QA para PRs: início após aprovação, VMs de curta duração, relatório no PR e no firebirdtest.com	custo único	—	US$ 1.500
Desenvolvimento do agente de primeira análise: integração com GitHub, regras do projeto	custo único	—	US$ 1.000
Reserva: discos e tráfego na nuvem, aumento de preços, crescimento de PRs	5% da meta	—	US$ 1.000
Agente de IA: assinatura de serviço de IA	assinatura fixa	US$ 100	US$ 600
Taxas de pagamento	4% da meta	—	US$ 800
Execuções Windows para PRs: Azure D4s v5 Windows	subconjunto obrigatório e suíte completa por classe de PR, +20% para repetições	US$ 50	US$ 299,26
Execuções Linux: DigitalOcean General Purpose 16 GB	execuções de PR por classe, +20% para repetições, e OLTP-EMUL noturno para 5.0 e 6.0	US$ 37	US$ 224,86
Expansão de testes para 6.0 e maior intensidade: Linux e Windows	builds alpha e beta, mais PRs, crescimento da suíte, +20% para repetições	US$ 25	US$ 150,14
Armazenamento para logs, crash dumps e bancos de dados: DigitalOcean Spaces	250 GB e 1 TB de tráfego	US$ 5	US$ 30
Total			US$ 18.402,26

Como calculamos as execuções. Execuções em nuvem para PRs: 127 PRs previstos, por classe de complexidade, com o subconjunto obrigatório a cada push e a suíte completa antes do merge de PRs grandes; veja os detalhes em “Quanto custa o QA para PRs por seis meses”. A linha de Linux também inclui o OLTP-EMUL noturno para as versões 5.0 e 6.0 nos dias com commits: cerca de 24 medições por mês, US$ 47,25 por seis meses. A expansão da 6.0 é uma linha separada: US$ 78,18 no Linux e US$ 71,95 no Windows; veja “Expansão de testes para a 6.0 e maior intensidade de testes”. As execuções noturnas da suíte de testes continuam rodando nos servidores da IBSurgeon e servem como linha de base para comparação.

O agente de IA cabe em US$ 100 por mês. A análise de um PR (cerca de 200 mil tokens de entrada e 10 mil tokens de saída) custa cerca de US$ 1, mesmo no modelo mais potente. Isso representa cerca de US$ 80 por mês: uma análise para cada novo PR e uma nova análise após atualizações. Com mais PRs após o alpha, o valor fica em torno de US$ 90.

O valor da bolsa, US$ 2.133 por mês, segue o plano do projeto. As linhas de nuvem são calculadas com os preços atuais e tempos reais de execução. Para o subconjunto obrigatório, que ainda precisa ser selecionado, utilizamos o tempo-alvo de 1 hora por sistema operacional.

Financiamento coletivo para melhorar o QA

O primeiro passo da reforma já começou: em 8 de outubro de 2026, a Firebird Foundation anunciou uma campanha de financiamento coletivo para melhorar o QA. A meta é arrecadar um valor adicional de US$ 20.000 em seis meses.

O dinheiro será destinado a duas áreas:

• o tempo de engenheiros de QA;
• máquinas virtuais para execuções de QA, em primeiro lugar para testes de desempenho.

No início da campanha, em 8 de outubro de 2026, 93 pull requests abertos aguardavam verificações e testes de QA. A regra do projeto não muda: nenhuma alteração recebe merge sem revisão e testes. Doações de qualquer valor são aceitas na página da campanha.

O que você ganha e como ajudar

Investir em QA é um seguro para todos que mantêm dados no Firebird. Um bug capturado antes do lançamento custa horas de trabalho de um engenheiro. Um bug que passa despercebido custa tempo de inatividade (downtime) e perda de dados para milhares de usuários.

O que usuários e patrocinadores ganham:

• as regressões ficam visíveis no próprio PR, antes do merge, e não na manhã seguinte a ele;
• lançamentos estáveis das branches 3.0–5.0 e da futura 6.0, sem regressões nem quedas de desempenho;
• um caminho mais rápido entre o relato de um bug e a sua correção, porque a verificação deixa de ser o gargalo;
• a capacidade de aceitar com segurança mais alterações externas, incluindo alterações preparadas com auxílio de IA;
• transparência: os resultados de todas as execuções permanecem públicos no firebirdtest.com, e haverá um relatório de despesas.

Como ajudar:

• Apoie a campanha de financiamento coletivo do QA com qualquer valor. Essa é a maneira mais direta de ajudar a reforma do QA.
• Apoie o projeto por meio da Firebird Foundation, com uma doação única ou assinatura (Associado: € 100 por ano; Parceiro: € 400 por ano).
• Torne-se um patrocinador corporativo: os termos são discutidos individualmente com a Firebird Foundation.
• Forneça recursos de nuvem ou créditos na DigitalOcean, Azure ou AWS para máquinas de teste.
• Ajude com pessoas: aloque um engenheiro para verificar PRs ou escrever testes no firebird-qa.

Fontes

Os dados de issues e pull requests são calculados para o repositório FirebirdSQL/firebird: contagens de PRs e issues via GitHub Search API, por data de criação; autores, tamanhos de PR e contagens de iterações a partir do histórico das branches refs/pull; classes de PR a partir de 214 PRs ao longo de 12 meses; a proporção de commits diretos a partir do histórico da branch master. As contagens de testes e seu crescimento vêm do histórico do repositório firebird-qa; os tempos e a frequência de execução vêm dos relatórios do firebirdtest.com. Dados de 9 de outubro de 2026.

• Firebird Foundation: Crowdfunding to improve Firebird QA
• FirebirdSQL/firebird: release 5.0.4
• FirebirdSQL/firebird-qa
• Firebird QA Results: firebirdtest.com
• firebirdtest.com: all tests for 35 runs, branch 6.0, Linux
• firebirdtest.com: OLTP-EMUL, Firebird
• Firebird QA: firebirdsql.org
• Firebird: Roadmap v6
• Firebird OLTP-EMULator test: IBSurgeon
• Firebird (database server): Wikipedia
• Support Firebird: Firebird Foundation
• GitHub Docs: Managing GitHub Actions settings for a repository
• GitHub Docs: Actions limits
• FirebirdSQL/firebird: CI runs
• DigitalOcean: Droplet pricing
• DigitalOcean: Spaces Object Storage pricing
• Azure Retail Prices API: D4s v5, West Europe
• GitHub Octoverse 2025
• BleepingComputer: curl ending bug bounty program
• DevClass: GitHub itself to blame for AI slop PRs, say devs