Como você contribui com patches para o núcleo do Drupal?

Qual é o processo adequado para contribuir com patches no núcleo do Drupal?

Digamos que eu encontre um bug no núcleo do Drupal, corrija-o e crie um patch . Como faço para enviá-lo?

Se o bug estiver no Drupal 7, também devo corrigi-lo no Drupal 8 e enviar dois patches? Isso também se aplica a bugs / melhorias na documentação?

Todos os patches também exigem um teste de unidade?

Se o bug estiver no Drupal 7, também devo corrigi-lo no Drupal 8 e enviar dois patches?

Se o bug estiver presente na versão em desenvolvimento (neste caso, Drupal 8) e na versão anterior (Drupal 7), o bug deverá primeiro ser corrigido na versão atualmente desenvolvida e, em seguida, nas versões anteriores.

Se o bug não estiver presente na versão mais recente desenvolvida, por exemplo, porque é para uma função que foi removida ou que já foi alterada, o patch deve ser fornecido para a versão anterior à desenvolvida atualmente.

O fluxo de trabalho a seguir é:

• Primeiro, o patch é criado e enviado para revisões da versão mais recente, mesmo que ainda esteja em desenvolvimento (como no caso do Drupal 8)
• Depois que o patch é aplicado ao Drupal, um patch que se aplica à versão anterior é criado e enviado para revisão

Você pode criar patches para duas versões do Drupal ao mesmo tempo, mas como o patch para a versão mais recente do Drupal pode exigir alterações, é melhor trabalhar no patch da versão atualmente desenvolvida do que trabalhar em dois patches diferentes que exigem ser alterado.

Consulte também: Política de Backport .

Isso também se aplica a bugs / melhorias na documentação?

Sim. Também neste caso, se a versão desenvolvida no momento removeu a função / método a que a documentação está se referindo, o patch precisa ser fornecido para a versão anterior.

Todos os patches também exigem um teste de unidade?

Se o patch for para a documentação, ele não requer testes. O bot de teste em execução em http://qa.drupal.org verifica o código do Drupal após a aplicação do patch; se o patch apresentar erros de sintaxe (por exemplo, porque o comentário foi fechado antes do necessário), o bot de teste relatará um erro sobre o patch antes da execução dos testes.

Se o patch for para um novo recurso, os testes serão necessários.

Se o patch for para corrigir um bug, os testes poderão ser solicitados pelos mantenedores, se ainda não houver um teste verificando um recurso específico. O teste geralmente é necessário para evitar a reintrodução do mesmo bug ao alterar no futuro o mesmo código. Se o erro for apenas uma variável inicializada, mas nunca usada de uma função / método, é provável que os testes não sejam necessários.

Toda página de projeto no drupal.org possui uma guia "Controle de versão" na parte superior. Ele fornece não apenas uma excelente visão geral de todas as opções de repositório de código para um projeto específico, mas todos os exemplos de comando git também são personalizados para o projeto. Você também pode alterá-lo interativamente para uma versão específica.

Para o núcleo do Drupal, você encontra essa página em http://drupal.org/project/drupal/git-instructions

Depois de criar seu patch, basta anexar o arquivo do patch a um problema que explica o que o patch faz.

Duas coisas importantes a destacar é garantir que o patch esteja terminando com ".patch" e definir o status como "Precisa de revisão". Isso para que o testbot o observe e execute automaticamente o teste.

O novo código sempre precisa ser acompanhado por testes .

Observe que isso é possível desativar por projetos e alguns o fazem. No núcleo do Drupal, ele está ativado, portanto todos os patches serão testados.

Você pode encontrar mais em http://drupal.org/contribute/development .