brintos

brintos / linux-shallow public Read only

0
0
Text · 2.8 KiB · e0ad636 Raw
61 lines · plain
1.. include:: ../../disclaimer-ita.rst2 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 sviluppatori7=============================================================8 9Introduzione10------------11 12L'insieme di istruzioni RISC-V sono sviluppate in modo aperto: le13bozze in fase di sviluppo sono disponibili a tutti per essere14revisionate e per essere sperimentare nelle implementazioni.  Le bozze15dei nuovi moduli o estensioni possono cambiare in fase di sviluppo - a16volte in modo incompatibile rispetto a bozze precedenti.  Questa17flessibilità può portare a dei problemi di manutenzioni per il18supporto RISC-V nel kernel Linux. I manutentori Linux non amano19l'abbandono del codice, e il processo di sviluppo del kernel20preferisce codice ben revisionato e testato rispetto a quello21sperimentale.  Desideriamo estendere questi stessi principi al codice22relativo all'architettura RISC-V che verrà accettato per l'inclusione23nel kernel.24 25Patchwork26---------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-V33hanno probabilmente richiesto delle modifiche o si aspettano che venga applicata34a un altro albero.35 36Il processo automatico viene eseguito su questa istanza di patchwork, costruendo37e collaudando le patch man mano che arrivano. Il processo applica le patch al38riferimento 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. In40caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è41stata applicata una serie di patch sarà annotato su patchwork. È improbabile che42vengano applicate Le patch che non passano i controlli, nella maggior parte dei43casi dovranno essere ripresentate.44 45In aggiunta alla lista delle verifiche da fare prima di inviare una patch46-------------------------------------------------------------------------47 48Accetteremo le patch per un nuovo modulo o estensione se la fondazione49RISC-V li classifica come "Frozen" o "Retified".  (Ovviamente, gli50sviluppatori sono liberi di mantenere una copia del kernel Linux51contenente il codice per una bozza di estensione).52 53In aggiunta, la specifica RISC-V permette agli implementatori di54creare le proprie estensioni.  Queste estensioni non passano55attraverso il processo di revisione della fondazione RISC-V.  Per56questo motivo, al fine di evitare complicazioni o problemi di57prestazioni, accetteremo patch solo per quelle estensioni che sono58state ufficialmente accettate dalla fondazione RISC-V.  (Ovviamente,59gli implementatori sono liberi di mantenere una copia del kernel Linux60contenente il codice per queste specifiche estensioni).61