Lines Matching refs:patch
11 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
37 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
41 Procedura per sottomettere patch per i sorgenti -stable
44 - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo
57 Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
64 nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
73 Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
74 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
83 Inviata la patch, dopo aver verificato che rispetta le regole descritte in
86 del kernel nel quale vorreste vedere la patch.
93 particolarmente utile se la patch ha bisogno di qualche modifica per essere
97 Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
100 della patch.
103 al messaggio della patch, così:
109 In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
130 Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
148 - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
149 coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni
151 - Se accettata, la patch verrà aggiunta alla coda -stable per essere
160 patch vengono mandate al comitato per la revisione, ai manutentori soggetti
161 alle modifiche delle patch (a meno che il mittente non sia anche il
165 alle patch.
166 - Se una patch viene rigettata da un membro della commissione, o un membro
167 della lista linux-kernel obietta la bontà della patch, sollevando problemi
168 che i manutentori ed i membri non avevano compreso, allora la patch verrà
170 - Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK
173 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
181 - La coda delle patch, sia quelle già applicate che in fase di revisione,