2. Como contribuir

2.1. Relatórios de Erro e Comentários em Geral

Uma idéia ou sugestão técnica de interesse geral deve ser enviada para a lista de discussões técnicas FreeBSD (hackers) [English Content/Conteúdo em Inglês] <freebsd-hackers@FreeBSD.org>. Da mesma forma, pessoas com interesse neste tipo de assunto (e uma tolerância para um alto volume de mensagens!), devem se inscrever na lista de discussões técnicas FreeBSD (hackers) [English Content/Conteúdo em Inglês] <freebsd-hackers@FreeBSD.org> através do envio de um e-mail para <majordomo@FreeBSD.org>. Consulte o Manual do FreeBSD para maiores informações sobre esta e outras listas de discussão.

Se você encontrar um erro ou estiver enviando uma alteração específica; por favor, faça o relatório utilizando o programa send-pr(1) ou a sua interface WWW equivalente. A não ser que ele exceda 65KB, inclua qualquer patch diretamente no relatório. Se o patch é destinado a ser aplicado na árvore de código, coloque a palavra [PATCH] na sinópse do relatório. Quando incluir um patch, não o faça utilizando copiar-e-colar porque ao copiar-e-colar os tabs serão convertidos para espaços, e tornará o patch inutilizável. Se o patch ultrapassar 20KB considere a possibilidade de comprimi-lo e utilizar o uuencode(1) antes de enviá-lo.

Depois de enviar o relatório, voce deve receber uma confirmação junto com um número de registro. Guarde este número de registro, de forma que você possa nos manter atualizados sobre o seu problema enviando um e-mail para <bug-followup@FreeBSD.org>. Coloque o número no assunto da mensagem, por ex. "Re: kern/3377". Informações adicionais sobre qualquer relatório de problema (Problem Report) devem ser submetidas desta forma.

Se você não receber a confirmação em prazo razoável (3 dias a 1 semana, dependendo da sua conexão de e-mail), ou está por alguma razão impossibilitado de utilizar o comando send-pr(1) ; então, você pode pedir que alguém o envie para você enviando e-mail para lista de discussão FreeBSD de relatório de problemas (PR) [English Content/Conteúdo em Inglês] <freebsd-bugs@FreeBSD.org>.

Consulte também este artigo sobre como escrever um bom relatório de problema.

2.2. Alterações na Documentação

Alterações na documentação são administradas pela lista de discussão do projeto de documentação do FreeBSD [English Content/Conteúdo em Inglês] <freebsd-doc@FreeBSD.org>. Por favor, verifique o Primer do Projeto de Documentação do FreeBSD para obter instruções detalhadas. Envie suas colaborações e alterações (inclusive as pequenas são bem vindas!) usando o send-pr(1) como descrito no Relatórios de Erro e Comentários em Geral.

2.3. Alterações no Código Fonte Existente

Uma adição ou alteração ao código fonte existente é um caso um pouco mais complicado e depende muito de quão desatualizado você está em relação ao estado atual de desenvolvimento do FreeBSD. Existe um lançamento (release) especial em andamento do FreeBSD conhecido como “FreeBSD-CURRENT” o qual é disponibilizado em uma grande variedade de formas para a comodidade dos desenvolvedores que trabalham ativamente no sistema. Consulte o Manual do FreeBSD para maiores informações sobre como obter e utilizar o FreeBSD-CURRENT.

Trabalhar com versões antigas do código, infelizmente, muitas vezes significa que as suas alterações serão demasiadamente obsoletas ou muito divergentes para possibilitar uma fácil re-integração ao FreeBSD. As possibilidades de que isso ocorra podem ser minimizadas um pouco através da sua inscrição nas listas lista de discussão FreeBSD anúncios [English Content/Conteúdo em Inglês] <freebsd-announce@FreeBSD.org> e lista de discussão FreeBSD-CURRENT [English Content/Conteúdo em Inglês] <freebsd-current@FreeBSD.org>, nas quais as discussões sobre o estado atual do sistema ocorrem.

Supondo que você consiga obter acesso à código fonte do sistema razoavelmente atualizado para basear as suas alterações nele, o próximo passo é produzir um conjunto de diffs para enviar aos mantenedores do FreeBSD. Isto é feito com o comando diff(1).

O formato preferido do diff(1) para enviar um patch, é o formato de saída unificada gerado por diff -u. No entando, para patches que alterem substancialmente uma região do código, o formato de saída de contexto gerada por diff -c pode ser mais legível e por isso preferido.

Por exemplo:

% diff -c oldfile newfile

ou

% diff -c -r olddir newdir

geraria o tal conjunto de diffs de contexto para um dado arquivo de código ou para uma hierarquia de diretórios.

Da mesma forma,

% diff -u oldfile newfile

ou

% diff -u -r olddir newdir

faria o mesmo, exceto que utilizando o formato de diff unificado.

Consulte o manual do diff(1) para maiores detalhes.

Uma vez que você tenha o conjunto de diffs (os quais você pode testar com o comando patch(1)), você deve submetê-los para inclusão no FreeBSD. Utilize o comando send-pr(1) como descrito no Relatórios de Erro e Comentários em Geral. Não envie os diffs apenas para a lista de discussões técnicas FreeBSD (hackers) [English Content/Conteúdo em Inglês] <freebsd-hackers@FreeBSD.org> ou eles serão perdidos! Nós apreciamos extremamente a sua submissão (este é um projeto voluntário!); porque nós somos ocupados, nós podemos não ter como tratá-la imediatamente, mas ela permanecerá em nosso bando de dados de PRs até que nós o façamos. Marque a sua submissão incluindo a palavra [PATCH] na sinópse do relatório.

Se você sentir que é apropriado (por ex. você adicionou, deletou ou renomeou arquivos), empacote as suas mudanças em um arquivo tar e execute o programa uuencode(1) nele. Arquivos criados com o shar(1) também são bem vindos.

Se suas mudanças são de uma natureza potencialmente sensível, por ex. você está inseguro sob quais políticas de direito autoral as novas versões serão distribuídas ou se você simplesmente não está pronto para liberá-las sem realizar primeiro uma revisão cuidadosa; então, você deve enviá-las diretamente para o lista de discussão do grupo central (core team) FreeBSD [English Content/Conteúdo em Inglês] <freebsd-core@FreeBSD.org> ao invés de submetê-las com o send-pr(1). A lista de discussão do grupo central (core team) FreeBSD [English Content/Conteúdo em Inglês] <freebsd-core@FreeBSD.org> alcança um grupo muito menor de pessoas que cuidam de muitas das tarefas diárias do FreeBSD. Observe que este grupo também é muito ocupado e assim você só deve enviar um e-mail a eles se for realmente necessário.

Por favor, consulte a intro(9) e a style(9) para obter alguma informação sobre o estilo de codificação. Nós apreciaríamos se você estivesse ao menos ciente destas informações antes de submeter o seu código.

2.4. Código Novo ou Pacotes Principais de Valor Adicional (Major Value-Added Packages)

No caso de uma contribuição significativa de um trabalho de grande porte, ou a adição de uma nova característica importante ao FreeBSD, torna-se quase sempre necessário que se envie as alterações em um arquivo tar uuencoded ou então que se faça o upload das mesmas para um servidor WWW ou FTP para que as outras pessoas possam acessá-las. Se você não possui acesso a um servidor WWW ou FTP, pergunte em uma lista de discussão apropriada do FreeBSD se alguém pode hospedar essas alterações para você.

Quando se trabalha com grandes quantidades de código, o sensível assunto de direitos autorais invariavelmente vem a tona. Os direitos autorais aceitos para os códigos incluídos no FreeBSD são:

1. Os direitos autorais BSD. Este tipo de licensa é a mais preferível devido a sua natureza “não restritiva” e pela sua afinidade com iniciativas comerciais. Longe de desencorajar o uso comercial, o Projeto FreeBSD encoraja ativamente tais participações, uma vez que estes interesses comerciais podem eventualmente se converter em investimentos no próprio FreeBSD.

2. A licensa pública geral GNU, ou “GPL”. Esta licensa não é tão popular conosco, devido aos esforços extras que exigem de qualquer pessoa que venha a utilizar o código com finalidades comerciais, mas dada a grande quantidade de código GPL que nós necessitamos atualmente (compilador, montador assembler, formatador de texto, etc) seria tolice recusar contribuições adicionais sob esta licensa. O código sob a GPL também vai para uma parte diferente da árvore, mais especificamente para /sys/gnu ou /usr/src/gnu, de forma que é muito fácil identificá-lo para qualquer um que a GPL representa um problema.

As contribuições que vêm sob qualquer outro tipo de licensa devem ser cuidadosamente revisadas antes de sua inclusão no FreeBSD ser considerada. Contribuições com algum tipo de restrição particular ao seu uso comercial são geralmente rejeitadas, embora os autores sejam sempre incentivados a tornarem tais alteração disponíveis por meio de canais próprios.

Para colocar o seu trabalho sob licensa “estilo-BSD”, inclua o texto abaixo no início de cada um dos arquivos que você deseja proteger, substituindo o texto entre %% com as informações apropriadas:

Copyright (c) %%proper_years_here%%
    %%your_name_here%%, %%your_state%%  %%your_zip%%.
    All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer as
   the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    $Id$

Para a sua comodidade, uma cópia deste texto pode ser encontrada em /usr/share/examples/etc/bsd-style-copyright .

2.5. Dinheiro, Hardware ou Acesso Internet

Nós ficamos sempre muito felizes em aceitar doações para agregar a causa do Projeto FreeBSD, em um esforço voluntário como o nosso, um pouco pode significar muito! Doações de hardware também são muito importantes para expandir a nossa lista de periféricos suportados, uma vez que normalmente não temos recursos para comprar estes ítens nós mesmos.