Contribuindo para o FreeBSD

---

1.1. Tarefas em execução por não-programadores.

Muitas das pessoas que estão envolvidas com o FreeBSD não são programadores. O projeto inclui autores de documentação, Web designers, e pessoal de suporte. Tudo o que estas pessoas precisam para contribuir é algum tempo livre para investir e vontade de aprender.

1. Leia o FAQ e Manual do FreeBSD periodicamente. Se algo estiver mal explicado, desatualizado ou mesmo completamente errado; por favor, deixe-nos saber. Ou melhor, envie-nos uma correção. (SGML não é difícil de aprender, mas não há nenhuma objeção à submissões em formato ASCII).

2. Ajude a traduzir a documentação do FreeBSD para a sua língua nativa. Se a documentação já existir no seu idioma, você pode ajudar a traduzir novos documentos ou verificar se as traduções existentes estão atualizadas. Primeiro, verifique o FAQ sobre traduções no Primer do Projeto de Documentação do FreeBSD. Você não estará se comprometendo a traduzir todos os documentos do FreeBSD fazendo isto -- como um voluntário, você pode traduzir muitos ou poucos documentos, quantos desejar. Uma vez que alguém começa a traduzir, outros quase sempre se juntam ao esforço. Se você somente tiver tempo livre ou energia para traduzir uma pequena parte da documentação; por favor, traduza as instruções de instalação.

3. Leia a lista de discussão FreeBSD de perguntas genéricas [English Content/Conteúdo em Inglês] <freebsd-questions@FreeBSD.org> e o o grupo de notícias (newsgroup) comp.unix.bsd.freebsd.misc ocasionalmente (ou regularmente se possível). Pode ser muito recompensador compartilhar a sua experiência e ajudar outras pessoas a resolverem seus problemas; Muitas vezes apenas este processo o levará à aprender coisas! Estes fóruns também podem ser uma fonte de idéias para assuntos aos quais se dedicar.

---

1.2. Tarefas em execução por programadores

A maioria das tarefas listadas aqui requerem um investimento considerável de tempo ou conhecimento profundo do kernel do FreeBSD; ou, ambos. Entretanto, também existem muitas tarefas úteis que são apropriadas para os “hackers de final de semana”.

1. Se você executar o FreeBSD-CURRENT e tiver uma boa conexão Internet, existe uma máquina current.FreeBSD.org que produz um lançamento (release) completo uma vez por dia -- tente instalar diariamente o lançamento mais recente gerado e relate todas as falhas encontradas no processo.

2. Leia a lista de discussão FreeBSD de relatório de problemas (PR) [English Content/Conteúdo em Inglês] <freebsd-bugs@FreeBSD.org>. Pode existir um problema o qual você possa comentar construtivamente ou mesmo uma correção que possa testar. Ou, você pode ainda tentar reparar um dos problemas sozinho.

3. Se você souber de qualquer problema que tenha sido corrigido com sucesso no -CURRENT e cuja correção não tenha sido aplicada ao -STABLE após um intervalo razoável de tempo (normalmente algumas semanas), envie ao committer um lembrete educado.

4. Mova as contribuições de software para src/contrib na árvore do código fonte.

5. Tenha certeza que o código disponível em src/contrib está atualizado.

6. Compile o sistema (ou apenas uma parte dele) com warnings extras habilitados e remova os warnings.

7. Corrija warnings de ports que ainda fazem coisas ultrapassadas tais como utilizar gets() ou incluir malloc.h.

8. Se você contribuiu com algum dos ports, envie suas correções de volta aos autores originais (isto tornará sua vida mais fácil quando eles lançarem a próxima versão).

9. Consiga cópias de padrões formais tais como POSIX®. Você pode obter alguns links sobre estes padrões no sítio www FreeBSD C99 e Projeto de Conformidade com Padrões Posix. Compare o comportamento do FreeBSD àquele requerido pelo padrão. Se o comportamento diferir, particularmente em pontos sutis ou obscuros da especificação, envie-nos um PR sobre ele. Se você for capaz, descubra como corrigi-lo e inclua um patch em seu PR. Se você acredita que o padrão está errado, peça ao comitê de padrões que considere a pergunta.

10. Sugira novas tarefas para esta lista!

---

1.3. Trabalhe no banco de dados de PR (relatório de problemas)

A Lista de PRs do FreeBSD mostra todos os relatórios de problemas ativos no momento e os pedidos de melhoria que foram submetidos pelos usuários do FreeBSD. O banco de dados inclui tarefas para programadores e para não-programadores. Consulte os PRs abertos, e veja se algum deles é de seu interesse. Alguns deles podem ser tarefas muito simples que necessitam apenas que um par extra de olhos olhe para eles e confirme que a correção proposta funciona. Outros podem ser muito mais complexos, ou podem nem ter vindo com uma correção.

Comece com os PRs que ainda não foram atribuídos a ninguém. Se um PR estiver atribuído a outra pessoa, mas se parecer com algo que você possa cuidar, envie um e-mail para a pessoa encarregada do mesmo e pergunte se você pode trabalhar nele -- ele pode já ter um patch pronto para ser testado, ou você pode discutir novas idéias com ele.

---

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.