Diretrizes de Submissão de Remendos

Antes de submeter um remendo, verifique se já existe um remendo para a versão atual ou para uma versão anterior. Se existir um remendo para a versão anterior que se aplique sem erros (Observação: obter um deslocamento/discrepância ao aplicar o remendo não é um erro), basta deixar uma observação na lista e os(as) mantenedores(as) dos remendos copiarão o arquivo para a nova versão.

Um comando sugerido para criar o arquivo de remendo é:

Observe que esse não é uma exigência absoluta e você é livre para criar o remendo da maneira que desejar, desde que a exigência a seguir seja atendida. Ao criar o remendo, você deveria estar em um diretório logo acima do diretório do pacote, de forma que o remendo resultante possa ser aplicado com patch -p1 conforme as instruções atuais no livro.

O nome do arquivo do remendo deveria estar no seguinte formato:

${Nomepacote}-${Versãopacote}-${Nomeremendo}-${Versãoremendo}.patch

Nomepacote

Nome oficial do pacote. Certifique-se de seguir a mesma capitalização seguida pelo tarball oficial para o pacote (ou seja, cracklib seria cracklib-2.9.7, gcc seria gcc-10.2.0, etc). Mudar convenções (por exemplo, ',' ou '-' ou nomes diferentes de pacotes) não deveria ser uma consideração – cabe inteiramente ao fluxo de desenvolvimento como eles(as) empacotam os tarballs deles(as) e nós deveríamos refletir a convenção deles(as) de nomenclatura. Onde as descrições dos pacotes tiverem múltiplas palavras, essas palavras deveriam ser separadas por '_' para diferenciar entre os campos separados por '-' que temos no projeto de remendos atualmente.

Versãopacote

Versão em relação a qual o remendo se aplica.

Nomeremendo

Nome abreviado para o remendo (inclua também a arquitetura se o remendo for para uma arquitetura específica).

Versãoremendo

Versão do remendo (começando com 1, se não existir versão anterior). Esse campo é obrigatório.

O remendo deveria ter as seguintes informações, cada item em uma linha separada e na mesma ordem (certifique-se de seguir a capitalização dos cabeçalhos, de forma que seja mais fácil para scripts analisarem os campos):

Submetido Por

Nome e (ou) correio eletrônico do(a) submetente.

Data

Datar o Remendo Submetido no formato AAAA-MM-DD. É mais fácil para todos(as) entenderem o formato internacional; por favor, não use nenhum outro.

Versão Inicial do Pacote

Versão em relação a qual o remendo foi preparado inicialmente.

Situação de Fluxo de Desenvolvimento

Se o remendo foi submetido e (ou) aceito pelos(as) desenvolvedores(as) originais. A seguir estão algumas sugestões para esse campo junto com as explicações:

Não submetido – Específico do LFS

O remendo é específico para o LFS e não tem valor para o fluxo de desenvolvimento. Isso geralmente deveria ser evitado.

Não submetido – [Versão de Teste, Hack, Ausência de Mantenedor(a), ...]

O remendo não foi submetido ao fluxo de desenvolvimento por algum motivo – por exemplo, o remendo precisa ser testado adequadamente; o remendo é um hack que não será aceitável no fluxo de desenvolvimento; o(a) mantenedor(a) está ausente; ...

Oriundo do Fluxo de Desenvolvimento

O remendo foi submetido ao fluxo de desenvolvimento (não necessariamente por você) e estará disponível em um lançamento futuro.

Submetido ao Fluxo de Desenvolvimento

O remendo foi submetido ao fluxo de desenvolvimento (não necessariamente por você), mas ainda não existe nenhuma decisão proveniente dos(as) mantenedores(as).

Rejeitado pelo Fluxo de Desenvolvimento

O remendo foi submetido ao fluxo de desenvolvimento (não necessariamente por você), mas foi rejeitado pelos(as) mantenedores(as).

Se alguém além de você tiver submetido o remendo ao fluxo de desenvolvimento, por favor, reconheça a pessoa na seção Descrição. Além disso, sempre é útil adicionar um URI para a discussão relevante.

Origem

Onde o remendo se originou. Isso é útil para os(as) usuários(as) ao considerarem a aplicação do remendo. Por favor, mantenha esse campo curto e restrito a uma linha. Um URI para uma discussão em lista de discussão relativa ao remendo é o mais adequado para esse campo. Outra opção, se o remendo for retirado a partir de um pacote de distribuição, é a de escrever o nome da distribuição e o nome do pacote (por exemplo, mozilla-1.4-12.src.rpm da Redhat). Se o remendo for criado por você e não existir URI para referência, basta adicionar teu nome no campo.

Descrição

Descrição do que o remendo faz, links para mais informações relacionadas ao remendo, etc. Quanto mais informações você fornecer para possíveis aplicadores(as) do remendo, maiores serão as chances de ele ser usado. Se você estiver modificando um remendo existente, certifique-se de creditar ao autor original.

Observação: Veja-se o remendo amostra.

Remendos deveriam ser enviados para a lista de discussão blfs-dev. Os(As) mantenedores(as) dos remendos preferem receber URIs de download também junto com os remendos. Mesmo se você incluir um URI, por favor, anexe o remendo junto com tua submissão para os arquivamentos. Por favor, comprima (com gzip ou bzip2) os remendos, de forma que seja fácil para as pessoas baixar os remendos diretamente a partir dos arquivamentos da lista. Ao mesmo tempo, economiza alguma largura de banda. Os remendos serão comprimidos (com gzip ou bunzip2) antes do upload, de forma que possam ser visualizados on-line.