Come si contribuiscono le patch al core di Drupal?

Qual è il processo corretto per contribuire con patch al core di Drupal?

Diciamo che trovo un bug nel core di Drupal, lo risolvo e creo una patch . Come lo invio?

Se il bug si trova in Drupal 7, devo ripararlo anche in Drupal 8 e inviare due patch? Questo vale anche per bug / miglioramenti della documentazione?

Anche tutte le patch richiedono un test unitario?

Se il bug si trova in Drupal 7, devo ripararlo anche in Drupal 8 e inviare due patch?

Se il bug è presente nella versione in fase di sviluppo (in questo caso Drupal 8) e nella versione precedente (Drupal 7), allora il bug dovrebbe essere prima corretto la versione attualmente sviluppata, e poi sulle versioni precedenti.

Se il bug non è presente nell'ultima versione sviluppata, ad esempio perché il bug è per una funzione che è stata rimossa o che è già stata modificata, allora la patch dovrebbe essere fornita per la versione precedente a quella attualmente sviluppata.

Il flusso di lavoro che segue è:

• Innanzitutto la patch viene creata e inviata per la revisione, per la versione più recente, anche se ancora in fase di sviluppo (come nel caso di Drupal 8)
• Una volta applicata quella patch a Drupal, viene creata una patch che si applica alla versione precedente e viene sottoposta a revisione

Puoi creare patch per due versioni di Drupal contemporaneamente, ma poiché la patch per l'ultima versione di Drupal potrebbe richiedere modifiche, è meglio lavorare sulla patch per la versione attualmente sviluppata, piuttosto che lavorare su due diverse patch che richiedono entrambe essere cambiato.

Vedi anche: Politica di backport .

Questo vale anche per bug / miglioramenti della documentazione?

Sì, lo fa. Anche in questo caso, se la versione attualmente sviluppata ha rimosso la funzione / metodo a cui fa riferimento la documentazione, è necessario fornire la patch per la versione precedente.

Anche tutte le patch richiedono un test unitario?

Se la patch è per la documentazione, non richiede test. Il bot di test in esecuzione su http://qa.drupal.org verifica il codice Drupal dopo l'applicazione della patch; se la patch introduce errori di sintassi (ad esempio perché il commento viene chiuso prima del necessario), il bot di test segnalerà un errore sulla patch prima di eseguire i test.

Se la patch è per una nuova funzionalità, sono richiesti i test.

Se la patch deve correggere un bug, i manutentori potrebbero richiedere i test, se non esiste già un test che controlli una specifica funzionalità. Il test è generalmente necessario per evitare di reintrodurre lo stesso bug quando si modifica in futuro lo stesso codice. Se il bug è semplicemente una variabile inizializzata, ma mai utilizzata da una funzione / metodo, è probabile che i test non siano richiesti.

Ogni pagina del progetto su drupal.org ha una scheda "Controllo versione" in alto. Offre non solo un'ottima panoramica di tutte le opzioni di repository di codice per il progetto specifico, ma anche tutti gli esempi di comandi git sono personalizzati per il progetto. Puoi anche cambiarlo interattivamente in una versione specifica.

Per il core di Drupal trovi quella pagina su http://drupal.org/project/drupal/git-instructions

Quindi, una volta creata la patch, è sufficiente allegare il file patch a un problema che spiega cosa fa la patch.

Due cose importanti da sottolineare sono assicurarsi che la patch stia terminando con ".patch" e impostare lo stato su "Revisione dei bisogni". Questo in modo che il testbot lo noterà ed eseguirà automaticamente il suo test.

Il nuovo codice deve sempre essere accompagnato da test .

Si noti che questo è possibile disattivare per progetti e alcuni lo fanno. Per Drupal core è attivo, quindi verranno testate tutte le patch.

Puoi trovare di più su http://drupal.org/contribute/development .