6.4. Desenvolvimento de novos recursos

Dentro do projeto existem subprojetos que estão trabalhando em novos recursos. Esses projetos geralmente são feitos por uma pessoa [Jørgensen, 2001]. Todo projeto é livre para organizar o desenvolvimento como achar melhor. No entanto, quando é feito o merge do projeto (aplicado) à branch -CURRENT, ele deve seguir as diretrizes do projeto. Quando o código foi bem testado na branch -CURRENT e considerado estável o suficiente e relevante para a branch -STABLE, ele é mergeado à branch -STABLE.

Os requisitos do projeto são fornecidos como o desenvolvedor desejar, solicitações da comunidade em termos de solicitações diretas por correio, relatórios de problemas, financiamento comercial para o desenvolvimento de recursos ou contribuições da comunidade científica. Os desejos que estão sob a responsabilidade de um desenvolvedor são dados àquele desenvolvedor que prioriza seu tempo entre o pedido e seus desejos. Uma maneira comum de fazer isso é manter uma lista de tarefas mantidas pelo projeto. Itens que não são de responsabilidade de alguém são coletados em TODO-lists, a menos que alguém seja voluntário para assumir a responsabilidade. Todos os pedidos, sua distribuição e acompanhamento são tratados pela ferramenta Bugzilla.

A análise de requisitos acontece de duas maneiras. As solicitações que entram são discutidas em listas de discussão, tanto dentro do projeto principal quanto no subprojeto ao qual a solicitação pertence ou é gerada pela solicitação. Além disso, os desenvolvedores individuais no subprojeto avaliarão a viabilidade das solicitações e determinarão a priorização entre elas. Além dos arquivos das discussões que ocorreram, nenhum resultado é criado por essa fase que é incorporada ao projeto principal.

Como os pedidos são priorizados pelos desenvolvedores individuais com base em fazer o que eles acham interessante, necessário ou são financiados para fazer, não há estratégia geral ou priorização de solicitações que considerem como requisitos e acompanhamento de sua implementação correta. No entanto, a maioria dos desenvolvedores tem uma visão compartilhada de quais problemas são mais importantes e podem solicitar diretrizes da equipe de engenharia de release.

A fase de verificação do projeto é dupla. Antes de fazer o commit do código para a branch atual, os desenvolvedores solicitam que seu código seja revisado por seus pares. Esta revisão é, na maior parte, feita por testes funcionais, mas a revisão de código também é importante. Quando o código é "committed" para a branch, um teste funcional mais amplo ocorrerá, o que pode acionar mais revisões de código e depuração, caso o código não se comporte conforme o esperado. Esta segunda forma de verificação pode ser considerada como verificação estrutural. Embora os próprios subprojetos possam escrever testes formais, como testes de unidade, eles geralmente não são coletados pelo projeto principal e geralmente são removidos antes que o código seja "committed" na branch atual. [9]



[9] No entanto, mais e mais testes são executados ao construir o sistema (make world). Esses testes são, no entanto, uma adição muito nova e ainda não foi criada nenhuma estrutura sistemática para esses testes.

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>.