Contribuindo com o FreeBSD | FreeBSD Documentation Portal
Description: Como contribuir para o Projeto FreeBSD
Keywords: Contributing,FreeBSD,Non-Programmer Tasks,Programmer Tasks

# Contribuindo com o FreeBSD

Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD.

trademarks

FreeBSD is a registered trademark of the FreeBSD Foundation.

IEEE, POSIX, and 802 are registered trademarks of Institute of Electrical and Electronics Engineers, Inc. in the United States.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol.

Resumo

Este artigo descreve maneiras diferentes sobre como um indivíduo ou organização pode contribuir com o Projeto FreeBSD.

Então você quer contribuir para o FreeBSD? Isso é ótimo! O FreeBSD depende das contribuições de sua base de usuários para sobreviver. Suas contribuições não são apenas apreciadas, elas são vitais para o crescimento contínuo do FreeBSD.

Um grande e crescente número de colaboradores internacionais, de idades e áreas de experiência técnica muito diversas, desenvolvem o FreeBSD. Sempre há mais trabalho a ser feito do que pessoas disponíveis para fazê-lo, e mais ajuda sempre é apreciada.

Como voluntário, o que você faz é limitado apenas pelo que você quer fazer. No entanto, pedimos que você esteja ciente do que outros membros da comunidade FreeBSD esperarão de você. Você pode querer levar isso em consideração antes de decidir ser um voluntário.

O projeto FreeBSD é responsável por um ambiente completo de sistema operacional, em vez de apenas um kernel ou alguns utilitários espalhados. Como tal, nossas listas de TODO abrangem uma ampla gama de tarefas: desde documentação, teste beta e apresentação, até o instalador do sistema e tipos altamente especializados de desenvolvimento de kernel. Pessoas de qualquer nível de habilidade, em quase qualquer área, certamente podem ajudar o projeto.

Empresas comerciais envolvidas em empreendimentos relacionados ao FreeBSD também são incentivadas a entrar em contato conosco. Precisa de uma extensão especial para fazer seu produto funcionar? Você nos encontrará receptivos às suas solicitações, desde que não sejam muito absurdas. Você está trabalhando em um produto de valor agregado? Por favor, nos informe! Podemos trabalhar cooperativamente em algum aspecto disso. O mundo do software livre está desafiando muitas suposições existentes sobre como o software é desenvolvido, vendido e mantido, e instamos você a pelo menos dar uma segunda olhada.

## 1. O que é necessário

A lista a seguir de tarefas e subprojetos representa algo como uma amálgama de várias listas de TODO e de solicitações de usuários.

### 1.1. Tarefas contínuas não relacionadas à programação

Muitas pessoas envolvidas no FreeBSD não são programadoras. O Projeto inclui escritores de documentação, web designers e pessoas de suporte. Tudo o que essas pessoas precisam para contribuir é investir tempo e estar dispostas a aprender.

1. Leia periodicamente o FAQ e o Handbook. Se algo estiver mal explicado, ambíguo, desatualizado ou incorreto, avise-nos. Ainda melhor, envie-nos uma correção (AsciiDoc não é difícil de aprender, mas não há objeção a submissões em texto simples).

2. Ajude a traduzir a documentação do FreeBSD para seu idioma nativo. Se já existir documentação em seu idioma, você pode ajudar a traduzir documentos adicionais ou verificar se as traduções estão atualizadas e corretas. Primeiro, dê uma olhada no FAQ de traduções no FreeBSD Documentation Project Primer. Ao fazer isso, você não está se comprometendo a traduzir todos os documentos do FreeBSD - como voluntário, você pode traduzir tanto quanto desejar. Uma vez que alguém começa a traduzir, outros quase sempre se juntam ao esforço. Se você só tem tempo ou energia para traduzir uma parte da documentação, por favor, traduza as instruções de instalação.

3. Leia ocasionalmente (ou mesmo regularmente) a lista de discussão para perguntas gerais sobre o FreeBSD. Pode ser muito satisfatório compartilhar sua expertise e ajudar as pessoas a resolverem seus problemas; às vezes, você pode até aprender algo novo! Esses fóruns também podem ser uma fonte de ideias para melhorias.

### 1.2. Tarefas contínuas para programadores

A maioria das tarefas listadas aqui pode exigir um investimento considerável de tempo, um conhecimento aprofundado do kernel do FreeBSD, ou ambos. No entanto, também existem muitas tarefas úteis que são adequadas para "hackers de fim de semana".

1. Se você está executando o FreeBSD-CURRENT e tem uma boa conexão com a Internet, há uma máquina chamada `current.FreeBSD.org` que cria uma versão completa uma vez por dia - de tempos em tempos, tente instalar a versão mais recente dela e relate quaisquer falhas no processo.

2. Leia a lista de discussão para reportar erros no FreeBSD. Pode haver um problema no qual você possa comentar de forma construtiva ou com patches que possa testar. Ou você poderia até mesmo tentar corrigir um dos problemas sozinho.

3. Se você souber de correções de bugs que foram aplicadas com sucesso ao -CURRENT, mas ainda não foram mescladas ao -STABLE após um intervalo razoável (normalmente algumas semanas), envie um lembrete educado ao committer responsável.

4. Mova o software contribuído para src/contrib no diretório de código-fonte.

5. Certifique-se de que o código em src/contrib esteja atualizado.

6. Compile o de código-fonte do sistema (ou apenas parte dele) com avisos extras ativados e limpe os avisos. Uma lista de avisos de compilação também pode ser encontrada em nosso CI selecionando uma compilação e verificando "LLVM/Clang Warnings".

7. Corrija os avisos para ports que fazem coisas depreciadas, como usar `gets()` ou incluir malloc.h.

8. Se você contribuiu com quaisquer ports e teve que fazer mudanças específicas para o FreeBSD, envie seus patches de volta para os autores originais (isso facilitará sua vida quando eles lançarem a próxima versão).

9. Obtenha cópias dos padrões formais, como o POSIX®. Compare o comportamento do FreeBSD com o exigido pelo padrão. Se o comportamento for diferente, especialmente em cantos sutis ou obscuros da especificação, envie um PR sobre isso. Se puder, descubra como corrigi-lo e inclua um patch no PR. Se achar que o padrão está errado, peça ao organismo responsável pelos padrões para considerar a questão.

10. Sugira novas tarefas para esta lista!

### 1.3. Trabalhe no Banco de Dados de PR (Relatório de Problema) do FreeBSD

A lista de PRs do FreeBSD mostra todos os relatórios de problemas ativos e solicitações de aprimoramento que foram enviados pelos usuários do FreeBSD. O banco de dados de PRs inclui tarefas tanto para programadores quanto para não-programadores. Olhe através dos PRs abertos e veja se algo lhe interessa. Alguns desses podem ser tarefas muito simples que só precisam de um par extra de olhos para examiná-los e confirmar que a correção no PR é boa. Outros podem ser muito mais complexos, ou podem nem mesmo ter uma correção incluída.

Comece com os PRs que não foram atribuídos a mais ninguém. Se um PR foi atribuído a outra pessoa, mas parece algo que você pode lidar, envie um e-mail para a pessoa a quem foi atribuído e pergunte se você pode trabalhar nele - eles podem já ter um patch pronto para ser testado ou outras ideias que você possa discutir com eles.

### 1.4. Tarefas contínuas relacionadas a coleção de ports

A coleção de ports é um trabalho contínuo em andamento. Queremos fornecer aos nossos usuários um repositório de software de terceiros fácil de usar, atualizado e de alta qualidade. Precisamos que as pessoas doem parte de seu tempo e esforço para nos ajudar a alcançar esse objetivo.

Qualquer um pode se envolver e há muitas maneiras diferentes de fazer isso. Contribuir para os ports é uma excelente maneira de ajudar a "retribuir" algo ao projeto. Se você está procurando um papel contínuo ou um desafio divertido para um dia chuvoso, adoraríamos ter a sua ajuda!

Há várias maneiras fáceis de contribuir para manter a árvore de ports atualizada e em bom funcionamento:

- Encontre algum software legal ou útil e crie um port para ele.

- Há muitos ports que não têm mantenedor. Torne-se um mantenedor e adote-o (Adotando um port não mantido).

- Se você criou ou adotou um port, esteja ciente sobre O desafio para os mantenedores de ports.

- Quando você estiver procurando um desafio rápido, Encontre e conserte um port quebrado.

### 1.5. Escolha um dos itens da “página de idéias”

A lista de projetos e ideias para voluntários do FreeBSD também está disponível para pessoas dispostas a contribuir para o projeto FreeBSD. A lista é atualizada regularmente e contém itens para programadores e não-programadores, com informações sobre cada projeto.

## 2. Como Contribuir

As contribuições para o sistema geralmente se enquadram em uma ou mais das seguintes 5 categorias:

### 2.1. Relatórios de Bugs e Comentários Gerais

Uma ideia ou sugestão de interesse técnico geral deve ser enviada para a lista de discussão de assuntos técnicos relacionados ao FreeBSD. Da mesma forma, pessoas com interesse nesses assuntos (e tolerância para um volume alto de mensagens!) podem se inscrever na lista de discussão de assuntos técnicos relacionados ao FreeBSD. Consulte o Handbook do FreeBSD para obter mais informações sobre esta e outras listas de e-mail.

Se você está enviando um patch simples para o repositório src, considere enviar um pull request para o espelho do projeto no GitHub. Envios adequados devem:

- Estar pronto ou quase pronto para ser Commitado. Um committer deve ser capaz de aplicar este patch com menos de 10 minutos de trabalho adicional.

- Ele passa em todos os trabalhos de CI do GitHub.

- Você pode responder rapidamente a feedbacks.

- Ele afeta menos de 10 arquivos e as mudanças têm menos de 200 linhas. Mudanças maiores do que isso podem ser OK, ou você pode ser solicitado a enviar vários pull requests de um tamanho mais gerenciável.

- Cada mudança lógica é um commit separado dentro do pull request. As mensagens de commit para cada mudança devem seguir o guia de log de commit.

- Todos os commits têm o seu nome e um endereço de e-mail válido como você gostaria de vê-los no repositório do FreeBSD como autor. Endereços falsos do github.com não podem ser usados.

- O escopo do pull request não deve ser alterado durante a revisão. Se a revisão sugerir mudanças que expandam o escopo, crie um pull request independente.

- Commits de correção devem ser combinados com o commit que estão corrigindo. Cada commit em seu branch deve ser adequado para o repositório do FreeBSD.

- Os commits devem incluir uma ou mais linhas `Signed-off-by:` com nome completo e endereço de e-mail certificando o Certificado de Origem do Desenvolvedor.

Ao atualizar um pull request, por favor faça o rebase com um push forçado em vez de um commit de merge. Mudanças mais complexas podem ser submetidas como pull requests, mas podem ser fechadas se forem muito grandes, difíceis de manusear, tornarem-se inativas, precisarem de mais discussão na comunidade ou precisarem de uma revisão extensa. Por favor, evite criar grandes patches de limpeza abrangentes: eles são muito grandes e não têm o foco necessário para uma boa revisão. Patches mal direcionados podem ser redirecionados para um fórum mais apropriado para a resolução do patch.

Os pull requests submetidos ao repositório de ports podem ou não receber atenção, dependendo do interesse dos desenvolvedores. Por enquanto, para ter uma melhor experiência é melhor seguir o processo de submissão de ports descrito na seção Contribuindo com a coleção de ports .

A equipe de documentação também aceita pull requests via GitHub, mas ainda não estabeleceu nenhuma política para eles.

Se você encontrar um bug ou estiver enviando uma mudança específica, por favor relate-o usando o formulário de submissão de bug. Tente preencher cada campo do relatório de bug. A menos que excedam 65KB, inclua quaisquer patches diretamente no relatório. Se o patch for adequado para ser aplicado à árvore de código fonte, coloque `[PATCH]` na sinopse do relatório. Ao incluir patches, não use o copiar e colar, pois o copiar e colar transforma os tabs em espaços e os torna inutilizáveis. Quando os patches são muito maiores do que 20KB, considere comprimi-los (por exemplo, com gzip(1) ou bzip2(1)) antes de enviá-los.

Depois de enviar um relatório, você deve receber uma confirmação juntamente com um número de rastreamento. Guarde este número de rastreamento para que você possa nos atualizar com detalhes sobre o problema.

Veja também este artigo sobre como escrever bons relatórios de problemas.

### 2.2. Mudanças na Documentação

As mudanças na documentação são supervisionadas pelo lista de discussão do projeto de documentação do FreeBSD. Por favor, consulte o FreeBSD Documentation Project Primer para obter instruções completas. Envie submissões e alterações (mesmo as pequenas são bem-vindas!) usando o mesmo método que qualquer outro relatório de bug.

### 2.3. Mudanças no Código Fonte Existente

Uma adição ou mudança no código-fonte existente é um assunto um pouco mais complicado e depende muito de quão desatualizado você está em relação ao estado atual do desenvolvimento do FreeBSD. Há uma versão especial em andamento do FreeBSD conhecida como "FreeBSD-CURRENT" que está disponível de várias maneiras para a conveniência de desenvolvedores que trabalham ativamente no sistema. Veja o Handbook do FreeBSD para mais informações sobre como obter e usar o FreeBSD-CURRENT.

Trabalhar a partir de fontes mais antigos infelizmente significa que suas alterações às vezes podem ser muito obsoletas ou divergentes demais para uma reintegração fácil no FreeBSD. As chances disso podem ser minimizadas um pouco ao se inscrever nas listas lista de distribuição de comunicados oficiais do projeto FreeBSD e lista de discussão do FreeBSD-CURRENT, onde ocorrem discussões sobre o estado atual do sistema.

Assumindo que você consegue obter fontes razoavelmente atualizadas para basear suas alterações, o próximo passo é produzir um conjunto de diffs para enviar aos mantenedores do FreeBSD. Isso é feito com o comando diff(1).

A preferência do formato diff(1) para envio de correções é o formato de saída unificada gerado pelo `diff -u`.

    % diff -u oldfile newfile

ou

    % diff -u -r -N olddir newdir

Iria gerar um conjunto de diffs unificados para o arquivo ou hierarquia de diretórios de origem fornecidos.

Consulte diff(1) para obter mais informações.

Uma vez que você tem um conjunto de diffs (que você pode testar com o comando patch(1)), você deve enviá-los para inclusão no FreeBSD como um relatório de problema. Não envie apenas os diffs para a lista de discussão de assuntos técnicos relacionados ao FreeBSD, pois eles serão perdidos! Agradecemos muito sua contribuição (este é um projeto voluntário!); como estamos ocupados, pode ser que não consigamos lidar com isso imediatamente, mas ele permanecerá no banco de dados de PRs até que o façamos. Indique sua submissão incluindo `[PATCH]` no resumo do relatório.

Se você achar apropriado (por exemplo, você adicionou, removeu ou renomeou arquivos), agrupe suas alterações em um arquivo `tar`. Arquivos criados com o comando shar(1) também são bem-vindos.

Se a sua alteração for potencialmente sensível, como se você não tem certeza sobre questões de direitos autorais que regem a distribuição posterior, você deve enviá-la diretamente para core@FreeBSD.org em vez de enviar como um relatório de bug. O core@FreeBSD.org atinge um grupo muito menor de pessoas que fazem muito do trabalho diário no FreeBSD. Observe que esse grupo também é muito ocupado e, portanto, você só deve enviar e-mails a eles quando for realmente necessário.

Por favor, consulte intro(9) e style(9) para obter informações sobre o estilo de codificação. Agradecemos se você pelo menos estiver ciente dessas informações antes de enviar código.

### 2.4. Código Novo ou Pacotes de Grande Valor Adicionado

No caso de uma contribuição significativa de um grande volume de trabalho, ou a adição de um novo recurso importante ao FreeBSD, torna-se quase sempre necessário enviar as alterações como arquivos tar ou carregá-los em um website ou FTP para que outras pessoas possam acessá-los. Se você não tem acesso a um website ou FTP, peça em uma lista de discussão apropriada do FreeBSD para alguém hospedar as alterações para você.

Quando se trabalha com grandes quantidades de código, a questão delicada de direitos autorais inevitavelmente surge. O FreeBSD prefere licenças de software livre tais como BSD ou ISC. Licenças copyleft como GPLv2 às vezes são permitidas. A lista completa pode ser encontrada na página da política de licenciamento do core team.

### 2.5. Dinheiro ou Hardware

Estamos sempre muito felizes em receber doações para promover a causa do Projeto FreeBSD e, em um esforço voluntário como o nosso, um pouco pode fazer muita diferença! As doações de hardware também são muito importantes para expandir nossa lista de periféricos suportados, já que geralmente não temos fundos para comprar tais itens nós mesmos.

#### 2.5.1. Doando Dinheiro

A FreeBSD Foundation é uma fundação sem fins lucrativos e isenta de impostos, estabelecida para promover os objetivos do projeto FreeBSD. Como uma entidade 501(c)3, a fundação é geralmente isenta de imposto de renda federal dos EUA, bem como do imposto de renda estadual do Colorado. As doações para uma entidade isenta de impostos muitas vezes são dedutíveis do imposto de renda federal tributável.

Doações podem ser enviadas em forma de cheque para:

The FreeBSD Foundation + 3980 Broadway Street + STE #103-107 + Boulder CO 80304 + USA

A FreeBSD Foundation também é capaz de receber doações online através de várias opções de pagamento.

Mais informações sobre a FreeBSD Foundation podem ser encontradas em The FreeBSD Foundation - uma introdução. Para entrar em contato com a Fundação por e-mail, escreva para info@FreeBSDFoundation.org.

#### 2.5.2. Doando Hardware

O Projeto FreeBSD alegremente aceita doações de hardware que possa ser utilizado de forma benéfica. Se você estiver interessado em doar hardware, por favor, entre em contato com o Departamento de Coordenação de Doações.

## 3. Contribuindo com a coleção de ports

### 3.1. Adotando um port não mantido

#### 3.1.1. Escolhendo um port não mantido

Assumir a manutenção de ports que não são mantidos é uma ótima maneira de se envolver. Os ports não mantidos são atualizados e corrigidos somente quando alguém se voluntaria para trabalhar neles. Há um grande número de ports não mantidos. É uma boa ideia começar adotando um port que você usa regularmente.

Os ports não mantidos têm seu campo `MAINTAINER` definido como `ports@FreeBSD.org`. Muitos ports não mantidos podem ter atualizações pendentes, que podem ser vistas no scanner de arquivos de distribuição dos Ports do FreeBSD.

Em PortsFallout, pode ser vista uma lista de ports sem manutenção com erros.

Alguns ports afetam um grande número de outros devido a dependências e relacionamentos de ports escravos. Geralmente, esperamos que as pessoas tenham alguma experiência antes de se voluntariarem para manter tais ports.

Você pode descobrir se um port possui dependências ou ports dependentes olhando para o índice mestre de ports chamado INDEX. (O nome do arquivo varia de acordo com a versão do FreeBSD; por exemplo, INDEX-8). Alguns ports têm dependências condicionais que não são incluídas em uma compilação padrão do INDEX. Esperamos que você seja capaz de reconhecer esses ports através da análise dos Makefile de outros ports.

#### 3.1.2. Como adotar um port

Primeiro, certifique-se de entender O desafio para os mantenedores de ports. Também leia o [porters-handbook]. Por favor, não se comprometa com mais do que você sente que pode lidar confortavelmente.

Você pode solicitar a manutenção de qualquer port não mantido assim que desejar. Basta definir `MAINTAINER` para o seu próprio endereço de e-mail e enviar um PR (Relatório de Problema) com a alteração. Se o port tiver erros de compilação ou precisar ser atualizado, talvez você queira incluir outras alterações no mesmo PR. Isso ajudará porque muitos committers estão menos dispostos a atribuir a manutenção a alguém que não tem um histórico conhecido com o FreeBSD. Enviar PRs que corrijam erros de compilação ou atualizem os ports são as melhores maneiras de estabelecer um histórico.

Envie seu PR com a categoria `ports` e a classe `change-request`. Um committer examinará seu PR, confirmará as alterações e, por fim, fechará o PR. Às vezes, esse processo pode levar um pouco de tempo (os committers também são voluntários :).

### 3.2. O desafio para os mantenedores de ports

Esta seção lhe dará uma ideia do motivo pelo qual os ports precisam ser mantidos e esboçará as responsabilidades de um mantenedor de port.

#### 3.2.1. Por que um port requer manutenção

Criar um port é uma tarefa única. Garantir que um port esteja atualizado e continue a ser compilado e executado requer um esforço contínuo de manutenção. Os mantenedores são as pessoas que dedicam parte do seu tempo para atender a esses objetivos.

A razão mais importante pela qual os ports precisam de manutenção é para trazer o que há de mais recente e melhor em software de terceiros para a comunidade FreeBSD. Um desafio adicional é manter os ports individuais funcionando dentro do framework da Coleção de Ports à medida que ele evolui.

Como mantenedor, você precisará gerenciar os seguintes desafios:

- Novas versões de software e atualizações. Novas versões e atualizações dos softwares portados se tornam disponíveis o tempo todo e precisam ser incorporadas na Coleção de Ports para fornecer software atualizado.

- Mudanças nas dependências. Se houverem mudanças significativas nas dependências do seu port, pode ser necessário atualizá-lo para que continue a funcionar corretamente.

- Mudanças que afetam ports dependentes. Se outros ports dependem de um port que você mantém, as alterações no seu port podem exigir coordenação com outros mantenedores.

- Interatividade com outros usuários, mantenedores e desenvolvedores. Parte de ser um mantenedor é assumir um papel de suporte. Não se espera que você forneça suporte geral (mas você é bem vindo se você optar por fazê-lo). O que você deve fornecer é um ponto de coordenação para problemas específicos do FreeBSD relacionados aos seus ports.

- Procura de bugs. Um port pode ser afetado por bugs específicos do FreeBSD. Você precisará investigar, encontrar e corrigir esses bugs quando forem relatados. Testar minuciosamente um port para identificar problemas antes que eles sejam incluídos na Coleção de Ports é ainda melhor.

- Mudanças na infraestrutura e políticas dos ports. Às vezes, os sistemas usados para compilar ports e pacotes são atualizados ou uma nova recomendação que afeta a infraestrutura é feita. Você deve estar ciente dessas mudanças no caso de seus ports serem afetados e precisarem de atualização.

- Mudanças no sistema base. O FreeBSD está em constante desenvolvimento. Mudanças no software, bibliotecas, kernel ou até mesmo mudanças de política podem causar a necessidade de alterações em cascata nos ports.

#### 3.2.2. Responsabilidades do mantenedor

##### Mantenha seus ports atualizados

Esta seção descreve o processo a ser seguido para manter seus ports atualizados.

Este é um resumo. Mais informações sobre atualização de um port estão disponíveis no Handbook do mantenedor de ports.

1. Preste atenção às atualizações

   Monitorar os fabricantes upstream em relação a liberação de novas versões, patches e correções de segurança para o software. Listas de discussão e de anúncios ou páginas web de noticias sobre o software são úteis para este propósito. Algumas vezes os usuários entrarão em contato com você perguntando quando seu port será atualizado. Se você estiver ocupado com outras atividades ou devido a qualquer outra razão não puder realizar a atualização naquele momento, pergunte se o usuário pode te ajudar enviando uma atualização.

   Você também pode receber e-mails automáticos do `FreeBSD Ports Version Check` informando que uma versão mais recente do arquivo de distribuição do seu port está disponível. Mais informações sobre esse sistema (incluindo como interromper futuros e-mails) serão fornecidas na mensagem.

2. Incorporar mudanças

   Quando estiverem disponíveis, incorpore as alterações no port. Você precisa ser capaz de gerar um patch entre o port original e o seu port atualizado.

3. Revisão e testes

   Examine cuidadosamente e teste as suas mudanças:

   - Compile, instale e teste seu port em quantas plataformas e arquiteturas puder. É comum um port funcionar em um branch ou plataforma e falhar em outro.

   - Certifique-se de que as dependências do seu port estejam completas. A maneira recomendada de fazer isso é instalando o seu próprio tinderbox. Consulte Recursos para mantenedores de ports e contribuidores para obter mais informações.

   - Verifique se a lista de pacotes está atualizada. Isso envolve adicionar quaisquer novos arquivos e diretórios e remover entradas não utilizadas.

   - Verifique seu port usando o comando portlint(1) como guia. Consulte Recursos para mantenedores de ports e contribuidores para obter informações importantes sobre o uso do portlint.

   - Considere se as alterações em seu port podem fazer com que outros ports se quebrem. Se for o caso, coordene as alterações com os mantenedores desses ports. Isso é especialmente importante se sua atualização alterar a versão da biblioteca compartilhada; nesse caso, pelo menos os ports dependentes precisarão receber um incremento no `PORTREVISION` para que sejam atualizados automaticamente por ferramentas automatizadas, como portmaster ou portupgrade(1).

4. Envie as alterações

   Envie sua atualização submetendo um PR com uma explicação das alterações e um patch contendo as diferenças entre o port original e o atualizado. Consulte o Redação de Relatórios de Problemas do FreeBSD para obter informações sobre como escrever um PR realmente bom.

   | Por favor, não envie um arquivo shar(1) do port inteiro; em vez disso, use git-format-patch(1) ou diff(1) `-ruN`. Dessa forma, os committers podem ver com muito mais facilidade exatamente quais mudanças estão sendo feitas. A seção Atualização do Handbook do Mantenedor de Ports contém mais informações.

5. Aguarde

   Em algum momento, um committer lidará com o seu PR. Isso pode levar minutos ou pode levar uma ou duas semanas - portanto, tenha paciência. Se levar mais tempo, procure ajuda em listas de discussão (lista de discussão sobre a coleção de ports do FreeBSD), no IRC: #bsdports na EFNet ou #freebsd-ports na Libera, por exemplo.

6. Dê feedback

   Se um committer encontrar um problema com as suas alterações, eles provavelmente o encaminharão de volta para você. Uma resposta rápida ajudará a obter a aprovação do seu PR mais rapidamente e é melhor para manter uma conversa ao tentar resolver qualquer problema.

7. E finalmente

   Suas alterações serão incorporadas e o seu port será atualizada. O PR será então fechado pelo committer. É isso aí!

##### Garanta que seus ports continuem a ser compilados corretamente

Esta seção é sobre a descoberta e a solução de problemas que fazem seus ports deixarem de ser compilados corretamente.

O FreeBSD garante o funcionamento da Coleção de Ports apenas nos branches `-STABLE`. Em teoria, você deveria ser capaz de rodar a versão mais recente de cada branch estável (já que as ABIs não devem mudar), mas se puder rodar o branch, isso é ainda melhor.

Como a maioria das instalações do FreeBSD é executada em máquinas compatíveis com PC (o que é chamado de arquitetura `i386`), esperamos que você mantenha o port funcionando nessa arquitetura. Preferimos que os ports também funcionem na arquitetura `amd64` executando nativamente. É completamente justo pedir ajuda se você não tiver uma dessas máquinas.

| Os modos comuns de falha para máquinas não-`x86` são que os programadores originais assumiram, por exemplo, que os ponteiros são `int`, ou que um compilador gcc mais antigo e relativamente relaxado estava sendo usado. Cada vez mais, os autores de aplicativos estão retrabalhando seu código para remover essas suposições - mas se o autor não estiver mantendo ativamente seu código, você pode precisar fazer isso sozinho.

Estas são as tarefas que você precisa realizar para garantir que o seu port possa ser compilado:

1. Fique atento a falhas na compilação

   Verifique seu e-mail para ver se há mensagens de `pkg-fallout@FreeBSD.org` e do scanner de distfiles para ver se algum dos ports que estão falhando na compilação está desatualizado.

2. Colete informação

   Assim que você estiver ciente de um problema, colete informações para ajudá-lo a corrigi-lo. Os erros de compilação relatados pelo `pkg-fallout` são acompanhados por logs que mostrarão onde a compilação falhou. Se a falha foi relatada por um usuário, peça a eles que enviem informações que possam ajudar a diagnosticar o problema, tais como:

   - Logs de compilação

   - Os comandos e opções usados para compilar o port (incluindo opções definidas no /etc/make.conf)

   - Uma lista de pacotes instalados no seu sistema, conforme mostrado por pkg-info(8)

   - A versão do FreeBSD que estão executando, conforme mostrado por uname(1) `-a`

   - Quando a coleção de ports foi atualizada pela última vez

   - Quando a sua coleção de ports e o arquivo INDEX foram atualizados pela última vez

3. Investigue e encontre uma solução

   Infelizmente, não há um processo direto a seguir para fazer isso. Lembre-se, no entanto: se estiver travado, peça ajuda! O lista de discussão sobre a coleção de ports do FreeBSD é um bom lugar para começar, e os desenvolvedores upstream geralmente são muito prestativos.

4. Envie as alterações

   Assim como na atualização de um port, agora você deve incorporar as alterações, revisar, testar e enviar suas alterações em um relatório de problemas (PR) e fornecer feedback, se solicitado.

5. Envie os patches para os autores upstream

   Em alguns casos, você terá que fazer patches no port para fazê-lo funcionar no FreeBSD. Alguns (mas não todos) os autores upstream aceitarão tais patches em seu código para a próxima versão. Se for o caso, isso pode até ajudar seus usuários em outros sistemas baseados em BSD e talvez economizar esforço duplicado. Considere enviar quaisquer patches aplicáveis aos autores como uma cortesia.

##### Investigue relatórios de bugs e PRs relacionados ao seu port

Esta seção é sobre como descobrir e corrigir bugs.

Os bugs específicos do FreeBSD são geralmente causados por suposições sobre os ambientes de compilação e de tempo de execução que não se aplicam ao FreeBSD. É menos provável que você encontre um problema desse tipo, mas ele pode ser mais sutil e difícil de diagnosticar.

Essas são as tarefas que você precisa realizar para garantir que seu port continue funcionando conforme o esperado:

1. Responda os relatórios de bugs

   Os bugs podem ser relatados a você por e-mail através do banco de dados de relatórios de problemas. Os bugs também podem ser relatados diretamente a você pelos usuários.

   Você deve responder a PRs e outros relatórios dentro de 14 dias, mas tente não levar tanto tempo. Tente responder o mais rápido possível, mesmo que seja apenas para dizer que você precisa de mais tempo antes de poder trabalhar no PR.

   Se você não respondeu após 14 dias, qualquer committer pode fazer o commit de um PR que você não respondeu através de um `maintainer-timeout`.

2. Colete informação

   Se a pessoa que reportou o bug também não forneceu uma correção, você precisa coletar as informações que permitirão gerar uma correção.

   Se o erro puder ser reproduzido, você pode coletar a maioria das informações necessárias por conta própria. Caso contrário, peça para a pessoa que relatou o erro coletar as informações para você, como:

   - Uma descrição detalhada das ações realizadas, comportamento esperado do programa e comportamento atual

   - Cópias dos dados de entrada usados para acionar o bug

   - Informações sobre o ambiente de compilação e execução - por exemplo, uma lista de pacotes instalados e a saída de env(1)

   - Core dumps

   - Stack traces

3. Elimine os relatórios incorretos

   Algumas notificações de bugs podem estar incorretas. Por exemplo, o usuário pode ter simplesmente utilizado o programa de forma inadequada ou seus pacotes instalados podem estar desatualizados e precisarem ser atualizados. Às vezes, um bug reportado não é específico do FreeBSD. Nesse caso, reporte o bug para os desenvolvedores upstream. Se o bug estiver dentro de suas capacidades de corrigir, você também pode corrigir o port para que a correção seja aplicada antes do próximo release upstream.

4. Encontre uma solução

   Tal como acontece com erros de compilação, você precisará encontrar uma correção para o problema. Mais uma vez, lembre-se de perguntar se você estiver emperrado!

5. Envie ou aprove alterações

   Assim como na atualização de um port, você deve incorporar as mudanças, revisar e testar e enviar suas mudanças em um PR (ou enviar um acompanhamento se já existir um PR para o problema). Se outro usuário tiver enviado mudanças no PR, você também pode enviar um acompanhamento dizendo se aprova ou não as mudanças.

##### Forneça Suporte

Parte de ser um mantenedor é fornecer suporte - não para o software em geral - mas para o port e quaisquer peculiaridades e problemas específicos do FreeBSD. Os usuários podem entrar em contato com você com perguntas, sugestões, problemas e patches. Na maioria das vezes, a correspondência deles será específica para o FreeBSD.

Ocasionalmente, você pode ter que invocar suas habilidades em diplomacia e gentilmente direcionar usuários que buscam suporte geral para os recursos apropriados. Com menos frequência, você encontrará alguém perguntando por que os `RPMS` não estão atualizados ou como eles podem fazer o software rodar no Foo Linux. Aproveite a oportunidade para dizer que seu port está atualizado (se estiver, é claro!) e sugira que eles experimentem o FreeBSD.

Às vezes, os usuários e os desenvolvedores podem decidir que você é uma pessoa ocupada cujo tempo é valioso e farão parte do trabalho para você. Por exemplo, eles podem:

- enviar um PR ou lhe enviar patches para atualizar o seu port,

- investigar e talvez fornecer uma correção para um PR, ou

- caso contrário, enviar alterações para o seu port.

Nesses casos, sua principal obrigação é responder de forma rápida. Novamente, o prazo para mantenedores não responsivos é de 14 dias. Após esse período, as alterações podem ser realizadas sem aprovação. Eles fizeram o esforço para ajudá-lo, então tente pelo menos responder prontamente. Em seguida, revise, aprove, modifique ou discuta as alterações com eles o mais rápido possível.

Se você puder fazê-los sentir que a contribuição deles é apreciada (e deveria ser), você terá uma chance maior de persuadi-los a fazer mais coisas para você no futuro :-).

### 3.3. Encontre e conserte um port quebrado

Existem alguns bons lugares para encontrar um port que precisa de atenção.

Você pode usar a interface web do banco de dados de Relatórios de Problemas para pesquisar e visualizar relatórios de problemas não resolvidos. A maioria dos relatórios de problemas para os ports são atualizações, mas com uma pequena busca e leitura das sinopses você deverá ser capaz de encontrar algo interessante para trabalhar (a classe `sw-bug` é um bom lugar para começar).

O PortsFallout mostra problemas de ports coletados durante a compilação de pacotes no FreeBSD.

Também é OK enviar alterações para um port que possui um mantenedor, mas lembre-se de perguntar ao mantenedor no caso de já estarem trabalhando no problema.

Depois de encontrar um bug ou problema, colete informações, investigue e corrija! Se houver um PR existente, faça um follow-up nela. Caso contrário, crie um novo PR. Suas alterações serão revisadas e, se tudo estiver correto, serão comitadas.

### 3.4. Quando desistir

À medida que seus interesses e compromissos mudam, você pode descobrir que não tem mais tempo para continuar com algumas (ou todas) as suas contribuições para a coleção de ports. Tudo bem! Por favor, nos avise se você não estiver mais usando um port ou se não tiver mais tempo ou interesse em ser um mantenedor. Desta forma, podemos seguir em frente e permitir que outras pessoas tentem trabalhar nos problemas existentes com o port sem termos que esperar por sua resposta. Lembre-se, o FreeBSD é um projeto voluntário, então se a manutenção de um port não for mais divertida, provavelmente é hora de deixar alguém fazer isso!

Em qualquer caso, a equipe de gerenciamento de ports (`portmgr`) se reserva o direito de redefinir sua posição de mantenedor se você não mantiver ativamente seu port por algum tempo. (Atualmente, este tempo é de 3 meses.) Com isso, queremos dizer que existem problemas não resolvidos ou atualizações pendentes que não foram trabalhadas durante esse tempo.

### 3.5. Recursos para mantenedores de ports e contribuidores

O Handbook do Mantenedor de Ports é o seu guia do sistema de ports. Mantenha-o sempre à mão!

o artigo Escrevendo Relatórios de Problemas do FreeBSD descreve como formular e submeter um PR da melhor maneira possível. Em 2005, mais de onze mil PRs de ports foram submetidos! Seguir este artigo ajudará muito a reduzir o tempo necessário para lidar com seus PRs.

O banco de dados de Relatórios de Problemas.

O scanner de arquivos de distribuição de ports do FreeBSD (portscout) pode mostrar os ports para os quais os arquivos de distribuição não podem ser baixados. Você pode verificar os seus próprios ports ou usá-lo para encontrar ports que precisam atualizar seus `MASTER_SITES`.

O ports-mgmt/poudriere é a maneira mais completa de testar um port por todo o ciclo de instalação, empacotamento e desinstalação. A documentação está localizada no repositório do GitHub do poudriere

O portlint(1) é um aplicativo que pode ser usado para verificar se o seu port está em conformidade com muitas diretrizes estilísticas e funcionais importantes. O portlint é uma aplicação heurística simples, portanto, você deve usá-lo apenas como guia. Se o portlint sugerir mudanças que parecem inaceitáveis, consulte o Porter’s Handbook ou peça conselhos.

A lista de discussão sobre a coleção de ports do FreeBSD é o local para discussões gerais relacionadas a ports. É um bom lugar para pedir ajuda. Você pode se inscrever, ou ler e pesquisar os arquivos da lista. Ler os arquivos das listas lista de discussão para relatar erros na coleção de ports do FreeBSD e mensagens de commit no repositório SVN para o head/ da árvore ports também pode ser interessante.

O PortsFallout é um site útil para buscar informações no arquivo de erros de pacotes do FreeBSD.

## 4. Começando em outras áreas

Procurando por algo interessante para começar, e que não foi mencionado em outras partes deste artigo? O Projeto FreeBSD tem várias páginas Wiki contendo áreas nas quais novos colaboradores podem ter ideias sobre como começar.

A página Junior Jobs contém uma lista de projetos que podem interessar pessoas que estão começando no FreeBSD e querem trabalhar em coisas interessantes para se familiarizar com o sistema.

A página de idéias contém várias sugestões de projetos "interessantes" ou "nice to have" para trabalhar no projeto.

Última alteração em: 18 de junho de 2026 por Alexander Ziaee