Capítulo 6. Processos

Índice
6.1. Adicionando novos committers e removendo committers antigos
6.2. Enviando código para o projeto (Committing code)
6.3. Eleição do Core
6.4. Desenvolvimento de novos recursos
6.5. Manutenção
6.6. Relatório de Problemas
6.7. Reagindo ao mau comportamento
6.8. Engenharia de Release (Versão)

A seção a seguir descreverá os processos definidos do projeto. Questões que não são tratadas por esses processos acontecem em uma base ad-hoc com base no que era costume fazer em casos semelhantes.

6.1. Adicionando novos committers e removendo committers antigos

O Core team tem a responsabilidade de fornecer e remover os privilégios de commit aos colaboradores. Isso só pode ser feito por meio de votação na lista de discussão do core. Os subprojetos de ports e documentação podem conceder privilégios de commit a pessoas que trabalham nesses projetos, mas até o momento não removeram esses privilégios.

Normalmente, um colaborador é recomendado para o core por um committer. Para colaboradores ou pessoas de fora entrar em contato com o core pedindo para ser um committer não é algo bem pensado e geralmente é rejeitado.

Se a área de interesse particular para o desenvolvedor potencialmente se sobrepuser à área de manutenção de outros committers, a opinião desses commiters mantenedores é solicitada. No entanto, é frequentemente esse committer que recomenda o desenvolvedor.

Quando um colaborador recebe status de committer, ele recebe um mentor. O committer que recomendou o novo committer, no caso geral, assumirá a responsabilidade de ser o novo mentor dos committers.

Quando um colaborador recebe seu commit bit, um e-mail assinado PGP é enviado de Core Secretary, Ports Manager ou nik@freebsd.org para ambos admins@freebsd.org, o mentor designado, o novo committer e o core confirmando a aprovação de uma nova conta. O mentor então reúne uma senha, a chave pública SSH 2 e a chave PGP do novo committer e as envia para Admin. Quando a nova conta é criada, o mentor ativa o commit bit e orienta o novo committer pelo resto do processo inicial.

Figura 6.1. Resumo do processo: adicionando um novo committer
Resumo do processo: adicionando um novo committer


Quando um colaborador envia uma parte do código, o committer que recebe pode optar por recomendar que o colaborador receba privilégios de commit. Se ele recomendar isso para o core, eles irão votar essa recomendação. Se eles votarem a favor, um mentor é designado ao novo committer e o novo committer tem que enviar seus dados para os administradores para que uma conta seja criada. Depois disso, o novo committer está pronto para fazer seu primeiro commit. Por tradição, isso é feito adicionando seu nome à lista de committers.

Lembre-se de que um committer é considerado alguém que tenha feito algum commit de código nos últimos 12 meses. No entanto, somente após 18 meses de inatividade terem se passado, os privilégios de commit são qualificados para serem revogados. [FreeBSD, 2002H] Não há, no entanto, procedimentos automáticos para fazer isso. Para reações a consentimentos de privilégios de commit não acionados pelo tempo, veja a seção 1.5.8.

Figura 6.2. Resumo do processo: removendo um committer
Resumo do processo: removendo um committer


Quando o Core decide limpar a lista de committers, eles checam quem não fez um commit nos últimos 18 meses. Os committers que não fizeram isso têm seus commit bit revogados.

Também é possível que os committers solicitem que seu commit bit seja retirado se, por alguma razão, eles não estiverem mais se comprometendo ativamente com o projeto. Nesse caso, ele também pode ser restaurado posteriormente pelo core, caso o committer peça.

Funções neste processo:

[FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I]

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