Upstream primeiro: um princípio fundamental do Fedora

O conceito de "upstream primeiro" é um princípio fundamental dentro do Projeto Fedora. Ele molda nossa história, cultura e abordagem para contribuir com o ecossistema de código aberto. Compreender esse princípio é crucial para qualquer pessoa que deseje contribuir com o Fedora e com o ecossistema mais amplo de distribuições Linux.

Compromisso do Fedora com upstream primeiro

O Fedora, como distribuição Linux, desempenha um papel único como integrador de inúmeros componentes de software. Embora o Fedora desenvolva alguns de seus próprios softwares, sua função principal é empacotar e fornecer uma experiência de sistema operacional coesa, construída sobre o trabalho de diversos projetos upstream.

Desde sua concepção, o Fedora defende o princípio de upstream primeiro. Isso não é uma política ou regra rígida; é um valor fundamental intrínseco à comunidade Fedora. Os colaboradores do Fedora acreditam que as alterações e melhorias em softwares de código aberto devem, sempre que possível, ser compartilhadas com os projetos upstream. Isso garante que todos os usuários desse software, e não apenas os usuários do Fedora, possam se beneficiar. Em última análise, o objetivo final do Fedora é o benefício do usuário, e os colaboradores do Fedora farão o que considerarem melhor para o usuário, mesmo que o upstream discorde.

Upstream primeiro também é um princípio pragmático de engenharia. Ao contribuir com alterações para o upstream, o Fedora reduz o fardo de manutenção a longo prazo de carregar patches específicos para cada projeto. Manter conjuntos de patches externos pode se tornar cada vez mais difícil à medida que os projetos originais evoluem. Adotar upstream primeiro ajuda a garantir a sustentabilidade do Fedora e suas contribuições.

Essa abordagem tem um efeito cascata em todo o ecossistema de código aberto. As mudanças implementadas no Fedora frequentemente impactam inúmeros projetos subsequentes que utilizam o Fedora como base. Portanto, contribuir para o Fedora é uma maneira altamente eficaz de influenciar e aprimorar o cenário mais amplo do código aberto, particularmente dentro do ecossistema RPM/Enterprise Linux.

Ao priorizar as contribuições upstream, o Fedora alinha-se com sua visão de um mundo onde todos se beneficiam de software livre e de código aberto, desenvolvido por comunidades inclusivas e acolhedoras. Esse compromisso se estende a todos os softwares de código aberto, não apenas ao próprio Fedora.

Entendendo upstream e downstream

No mundo do código aberto, os projetos frequentemente possuem relações interconectadas descritas como "upstream" e "downstream". O projeto upstream é a fonte original do software — a base sobre a qual outros projetos são construídos. Os projetos downstream, por sua vez, são aqueles que utilizam e, muitas vezes, modificam o software upstream. Pense nisso como um rio: o upstream é a nascente, e os projetos downstream estão mais adiante no fluxo, recebendo e potencialmente alterando a água.

Essa metáfora é essencial para entender como os projetos de código aberto dependem uns dos outros e interagem entre si. Diferentes modelos de desenvolvimento incentivam diversos tipos de relações upstream/downstream.

Comunicação aberta com upstream

O Fedora reconhece a importância de uma comunicação clara e aberta com os projetos upstream. Acreditamos em fomentar relacionamentos sólidos com os desenvolvedores e comunidades upstream e buscamos ativamente suas contribuições e feedback.

O Fedora está sempre aberto a ouvir os projetos upstream sobre como podemos melhorar nossos processos de colaboração e integração. Entendemos que o uso do Fedora por projetos downstream pode, às vezes, criar desafios ou atritos para esses projetos. Encorajamos os mantenedores upstream a entrarem em contato conosco caso encontrem algum problema ou tenham sugestões de melhoria.

Nosso objetivo é trabalhar juntos de forma construtiva para encontrar soluções que beneficiem tanto o Fedora quanto os projetos upstream dos quais dependemos. Embora nem sempre possamos atender a todas as solicitações upstream, estamos comprometidos em ouvir, aprender e adaptar nossas práticas para minimizar qualquer impacto negativo nas comunidades upstream.

A filosofia de trabalhar primeiro com os projetos upstream não se limita apenas ao desenvolvimento. Ela também engloba um relacionamento produtivo, positivo e respeitoso com nossos projetos upstream. Nossas comunidades se sobrepõem e queremos estender os valores do Fedora aos projetos delas tanto quanto fazemos dentro do próprio Fedora. Para isso, sempre buscamos lidar com os desafios entre os projetos em conjunto e manter canais de comunicação claros.

Quando que alterações downstream acontecem

Embora o Fedora priorize as contribuições upstream, há situações em que alterações específicas para cada projeto downstream são necessárias. Essas exceções não contradizem o princípio de upstream primeiro, mas sim reconhecem as complexidades do desenvolvimento e da distribuição de software.

Motivos para patches downstream incluem:

  • Rejeição do upstream: Às vezes, os mantenedores upstream podem rejeitar uma correção por vários motivos, mesmo que ela seja benéfica para o Fedora. O Fedora ainda pode precisar manter essa correção para resolver um problema ou atender a um requisito específico.

  • Progresso do upstream: Projetos upstream podem avançar com novos recursos ou alterações que exigem adaptação significativa no Fedora. O Fedora pode precisar fazer o backport de correções ou implementar soluções alternativas temporárias enquanto a adaptação downstream é concluída.

  • Necessidades específicas da distribuição: O Fedora e suas distribuições derivadas, como o EPEL, podem ter requisitos ou restrições exclusivas que exigem modificações subsequentes. Essas necessidades podem estar relacionadas ao suporte específico de hardware, considerações de segurança ou integração com outros componentes do Fedora.

  • Blobs não livres: O Fedora está comprometido em promover software livre e de código aberto e em construir tudo a partir do código-fonte. Às vezes, projetos upstream incluem blobs binários não livres ou pré-compilados que o Fedora precisa corrigir para aderir aos seus princípios. Embora o Fedora possa discutir possíveis correções com os projetos upstream, essas correções nem sempre serão aceitas se não houver alternativas adequadas ou se removerem funcionalidades.

Nessas situações, o Fedora se esforça para minimizar o escopo e a duração das correções downstream e continua trabalhando para incorporar as alterações upstream sempre que possível. Compreender os motivos das alterações downstream é essencial para manter a transparência e a confiança dentro da comunidade.

Exemplos em ação

O princípio de "upstream first" se manifesta de diversas maneiras. Aqui estão alguns exemplos:

  • Melhorias no empacotamento: Um empacotador do Fedora identifica um bug ou uma funcionalidade ausente em uma cadeia de ferramentas de compilação. Em vez de criar um patch específico para o Fedora, ele envia um patch para os mantenedores upstream da cadeia de ferramentas. Após revisão e discussão, o patch é incorporado ao código principal, beneficiando todos os usuários da cadeia de ferramentas e eliminando a necessidade de um patch específico para o Fedora.

  • Script da comunidade: Um colaborador do Fedora desenvolve um script para analisar dados de pacotes. Ele compartilha o script publicamente. Outro colaborador aprimora o script com novos recursos e envia uma solicitação de pull request. O colaborador original incorpora as alterações, disponibilizando o script aprimorado para toda a comunidade.

  • Esclarecimentos sobre licença: Um empacotador do Fedora descobre problemas de licenciamento em um projeto de código aberto, como licenças pouco claras ou não conformes para os recursos incluídos. Em vez de simplesmente excluir o projeto do Fedora, ele trabalha com os desenvolvedores originais para esclarecer ou corrigir as licenças. Isso garante que o projeto possa ser incluído no Fedora e beneficia a comunidade de código aberto em geral, promovendo a conformidade com as licenças.

  • Evitar dependências incluídas: Um empacotador do Fedora percebe que um projeto upstream inclui uma versão específica de uma dependência. Em vez de usar a dependência incluída (bundled), ele reempacota o projeto para usar a versão da dependência presente em todo o sistema. Isso garante consistência entre os pacotes do Fedora, permite a rápida implementação de patches de segurança e mantém a compatibilidade entre pacotes interdependentes.

  • Teste e relatório de erro antecipado: O Fedora costuma ser pioneiro na integração de novas versões de software e bibliotecas. Essa adoção antecipada permite que os colaboradores do Fedora identifiquem e relatem bugs de compilação ou compatibilidade diretamente ao projeto original, principalmente no ecossistema Python. Essas contribuições beneficiam toda a comunidade de código aberto, garantindo transições e atualizações mais tranquilas para todos.

Esses exemplos ilustram como a abordagem "upstream primeiro" promove a colaboração, a responsabilidade compartilhada e a melhoria contínua dentro do ecossistema de código aberto. Encorajamos você a pensar em como pode aplicar o princípio "upstream primeiro" em suas contribuições para o Fedora. Tem alguma história sobre uma contribuição para o projeto principal? Compartilhe com a comunidade!

Want to help? Learn how to contribute to Fedora Docs ›