6.5. Manutenção

É uma vantagem para o projeto que para cada área do código fonte tenha pelo menos uma pessoa que conheça bem essa área. Algumas partes do código designaram mantenedores. Outros têm mantenedores de fato, e algumas partes do sistema não possuem mantenedores. O mantenedor é geralmente uma pessoa do subprojeto que escreveu e integrou o código, ou alguém que o portou da plataforma para a qual foi escrito. [10] O trabalho do mantenedor é garantir que o código esteja em sincronia com o projeto de onde vem o código, se for um código contribuído, e aplicar correções enviadas pela comunidade ou escrever correções em problemas descobertos.

A maior parte do trabalho que é colocado no projeto FreeBSD é a manutenção. [Jørgensen, 2001] fez uma figura mostrando o ciclo de vida das mudanças.

Figura 6.6. O modelo de Jørgenssen para integração de mudanças
O modelo de Jørgenssen para integração de mudanças


Aqui, desenvolvimento de release (versão) refere-se a branch -CURRENT, enquanto o release em produção refere-se a branch -STABLE. O teste de pré-commit é o teste funcional feito por desenvolvedores de peers quando solicitado a fazê-lo ou a testar o código para determinar o status do subprojeto. Debug paralelo é o teste funcional que pode acionar mais revisões e debugs quando o código é incluído na branch -CURRENT.

A partir desta escrita, havia 269 committers no projeto. Quando eles fazem o commit de uma mudança em uma branch, isso constitui uma nova release (versão). É muito comum os usuários da comunidade rastrearem uma determinada branch. A existência imediata de uma nova release torna as mudanças amplamente disponíveis imediatamente e permite um feedback rápido da comunidade. Isso também dá à comunidade o tempo de resposta que eles esperam em questões que são importantes para eles. Isso torna a comunidade mais engajada e, assim, permite mais e melhores feedbacks que estimulam mais a manutenção e, por fim, deverá criar um produto melhor.

Antes de fazer alterações no código em partes da árvore que tem um histórico desconhecido para o committer, o committer é obrigado a ler os logs de commit para ver porque certos recursos são implementados da maneira que eles estão, para não cometer erros que foram anteriormente pensado ou resolvido.



[10] sendmail e named são exemplos de código que foi feito merge (aplicado o código) de outras plataformas.

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