Não existe um modelo definido para como as pessoas escrevem código no FreeBSD. No entanto, Niels Jørgenssen sugeriu um modelo de como o código escrito é integrado ao projeto.
A “versão de desenvolvimento” é a branch (ramificação) FreeBSD-CURRENT ("-CURRENT") e a “versão de produção ” é a branch (ramificação) FreeBSD-STABLE ("-STABLE") [Jørgensen, 2001].
Este é um modelo para uma mudança e mostra que, após a codificação, os desenvolvedores buscam a revisão da comunidade e tentam integrá-la com seus próprios sistemas. Depois de integrar a mudança na versão de desenvolvimento, chamada FreeBSD-CURRENT, ela é testada por muitos usuários e desenvolvedores na comunidade FreeBSD. Depois de passar por testes suficientes, é feito o merge (aplicado) na versão de produção, chamada FreeBSD-STABLE. A menos que cada estágio seja concluído com êxito, o desenvolvedor precisa voltar e fazer modificações no código e reiniciar o processo. Integrar uma mudança com -CURRENT ou -STABLE é chamado de fazer um commit.
Jørgensen descobriu que a maioria dos desenvolvedores do FreeBSD trabalha individualmente, o que significa que este modelo é usado em paralelo por muitos desenvolvedores nos diferentes esforços de desenvolvimento em andamento. Um desenvolvedor também pode estar trabalhando em várias alterações, de modo que, enquanto ele aguarda revisão ou que pessoas testem uma ou mais de suas alterações, ele pode estar escrevendo outra alteração.
Como cada commit representa um incremento, este é um modelo massivamente incremental. Os commits são tão freqüentes que durante um ano [3], 85427 commits foram feitos, fazendo uma média diária de 233 commits.
Dentro do processo “code” na figura de Jørgensen, cada programador tem seu próprio estilo de trabalho e segue seus próprios modelos de desenvolvimento. O suporte poderia muito bem ter sido chamado de “desenvolvimento”, pois inclui coleta e análise de requisitos, sistema e projeto detalhados, implementação e verificação. No entanto, a única saída desses estágios é o código-fonte ou a documentação do sistema.
Da perspectiva de um modelo em etapas (como o modelo em cascata), os outros suportes podem ser vistos como verificação adicional e integração do sistema. Essa integração do sistema também é importante para ver se uma alteração é aceita pela comunidade. Até que o código seja "committed", o desenvolvedor é livre para escolher quanto se deve comunicar sobre o restante do projeto. Para que o -CURRENT funcione como um buffer (para que as ideias brilhantes que tinham algumas desvantagens não descobertas possam ser recuperadas), o tempo mínimo que um "commit" deve estar no -CURRENT antes de fazer o merge (aplicar o código) para -STABLE é de 3 dias. Esse merge (aplicação) é referido como um MFC (Merge From Current).
É importante notar a palavra “change (mudança)”. A maioria dos commits não contém novos recursos radicais, mas são atualizações de manutenção.
As únicas exceções desse modelo são correções de segurança e alterações nos recursos que estão obsoletos na branch (ramificação) -CURRENT. Nesses casos, as alterações podem ser "committed" diretamente na branch -STABLE.
Além de muitas pessoas trabalhando no projeto, há muitos projetos relacionados ao Projeto FreeBSD. Estes são projetos desenvolvendo novos recursos, subprojetos ou projetos cujo resultado é incorporado ao FreeBSD [4]. Esses projetos se encaixam no Projeto FreeBSD, assim como os esforços regulares de desenvolvimento: eles produzem código que são integrados ao Projeto FreeBSD. No entanto, alguns deles (como Ports e Documentação) têm o privilégio de serem aplicáveis às duas branchs (ramificações) ou de commit diretamente na -CURRENT e na -STABLE.
Não há padrões para como o design deve ser feito, nem o design é coletado em um repositório centralizado. O design principal é o do 4.4BSD. [5] Como o design é parte do processo “Code (Código)” no modelo de Jørgenssen, cabe a cada desenvolvedor ou sub-projeto como isso deve ser feito. Mesmo que o projeto deva ser armazenado em um repositório central, a saída dos estágios do projeto seria de uso limitado, pois as diferenças de metodologias as desvalorizariam se de alguma forma interoperáveis. Para o design geral do projeto, o projeto conta com os subprojetos para negociar interfaces adequadas entre si, em vez de ditar interfaces.
[3] O período de 1º de janeiro de 2004 a 31 de dezembro de 2004 foi examinado para encontrar esse número.
[4] Por exemplo, o desenvolvimento da pilha Bluetooth começou como um subprojeto até ser considerada estável o suficiente para ser feito o merge (aplicado) na branch -CURRENT. Agora é parte do sistema principal do FreeBSD.
[5] De acordo com Kirk McKusick, depois de 20 anos desenvolvendo sistemas operacionais UNIX, as interfaces são, na maioria das vezes, resolvidas. Portanto, não há necessidade de muito design. No entanto, novas aplicações do sistema e novo hardware levam a algumas implementações sendo mais benéficas do que aquelas que costumavam ser ter preferencia. Um exemplo é a introdução da navegação Web que tornou a conexão TCP/IP normal uma sequência curta de dados, em vez de um fluxo contínuo durante um período de tempo mais longo.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.