1.. include:: ../../disclaimer-ita.rst 2 3:Original: :doc:`../../../../arch/riscv/patch-acceptance` 4:Translator: Federico Vaga <federico.vaga@vaga.pv.it> 5 6arch/riscv linee guida alla manutenzione per gli sviluppatori 7============================================================= 8 9Introduzione 10------------ 11 12L'insieme di istruzioni RISC-V sono sviluppate in modo aperto: le 13bozze in fase di sviluppo sono disponibili a tutti per essere 14revisionate e per essere sperimentare nelle implementazioni. Le bozze 15dei nuovi moduli o estensioni possono cambiare in fase di sviluppo - a 16volte in modo incompatibile rispetto a bozze precedenti. Questa 17flessibilità può portare a dei problemi di manutenzioni per il 18supporto RISC-V nel kernel Linux. I manutentori Linux non amano 19l'abbandono del codice, e il processo di sviluppo del kernel 20preferisce codice ben revisionato e testato rispetto a quello 21sperimentale. Desideriamo estendere questi stessi principi al codice 22relativo all'architettura RISC-V che verrà accettato per l'inclusione 23nel kernel. 24 25Patchwork 26--------- 27 28RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch: 29 30 https://patchwork.kernel.org/project/linux-riscv/list/ 31 32Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V 33hanno probabilmente richiesto delle modifiche o si aspettano che venga applicata 34a un altro albero. 35 36Il processo automatico viene eseguito su questa istanza di patchwork, costruendo 37e collaudando le patch man mano che arrivano. Il processo applica le patch al 38riferimento HEAD corrente dei rami `for-next` e `fixes` dei sorgenti RISC-V, 39questo a seconda che la patch sia stata o meno individuata come correzione. In 40caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è 41stata applicata una serie di patch sarà annotato su patchwork. È improbabile che 42vengano applicate Le patch che non passano i controlli, nella maggior parte dei 43casi dovranno essere ripresentate. 44 45In aggiunta alla lista delle verifiche da fare prima di inviare una patch 46------------------------------------------------------------------------- 47 48Accetteremo le patch per un nuovo modulo o estensione se la fondazione 49RISC-V li classifica come "Frozen" o "Retified". (Ovviamente, gli 50sviluppatori sono liberi di mantenere una copia del kernel Linux 51contenente il codice per una bozza di estensione). 52 53In aggiunta, la specifica RISC-V permette agli implementatori di 54creare le proprie estensioni. Queste estensioni non passano 55attraverso il processo di revisione della fondazione RISC-V. Per 56questo motivo, al fine di evitare complicazioni o problemi di 57prestazioni, accetteremo patch solo per quelle estensioni che sono 58state ufficialmente accettate dalla fondazione RISC-V. (Ovviamente, 59gli implementatori sono liberi di mantenere una copia del kernel Linux 60contenente il codice per queste specifiche estensioni). 61