Lines Matching refs:una
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
13 una certa familiarità col "sistema". Questo testo è una raccolta di
20 Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
55 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
65 sorgenti stabili o dai sorgenti di una distribuzione particolare che prende
69 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
95 Quando inviate o rinviate una patch o una serie, includete la descrizione
112 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
114 riferimento ad una discussione precedentemente avvenuta su una lista di
118 Quando volete fare riferimento ad una lista di discussione, preferite il
128 Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza
182 D'altro canto, se fate una singola modifica su più file, raggruppate tutte
183 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
184 è contenuto in una sola patch.
190 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
191 va bene. Semplicemente scrivete una nota nella descrizione della patch per
194 Quando dividete i vostri cambiamenti in una serie di patch, prestate
201 Se non potete condensare la vostra serie di patch in una più piccola, allora
202 pubblicatene una quindicina alla volta e aspettate che vengano revisionate
211 Non farlo porta semplicemente a una perdita di tempo da parte dei revisori e
222 Prima di inviare una patch, verificatene lo stile usando l'apposito
224 di stile dovrebbe essere visto come una guida, non come un sostituto al
225 giudizio umano. Se il vostro codice è migliore nonostante una violazione
240 Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
248 Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la
269 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
287 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
288 nel file MAINTAINERS), o almeno una notifica circa la vostra modifica,
300 una porzione specifica del vostro codice.
304 send-email``. Al sito https://git-send-email.io è disponibile una
334 essere ignorati. Riscontri o domande che non conducono ad una
343 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un
363 in una settimana o poco più; se questo non dovesse accadere, assicuratevi di
364 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
373 Ma non aggiungete "RESEND" quando state sottomettendo una versione modificata
397 La firma è una semplice riga alla fine della descrizione della patch che
428 poi dovete solo aggiungere una riga che dice::
446 **reale** che una patch a intrapreso dallo sviluppatore, fino al
456 Se una persona non è direttamente coinvolta con la preparazione o gestione
459 una riga Acked-by:.
470 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
476 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
479 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
485 associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
498 Esempio di una patch sottomessa dall'autore in From:::
508 Esempio di una patch sottomessa dall'autore Co-developed-by:::
543 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
552 sottomissione, credo che sia, in questo momento, (1) una modifica
562 una modifica che si ritiene appropriata e senza alcun problema tecnico
571 Quando si riceve una email sulla lista di discussione da un tester o
608 L'oggetto di una patch canonica è la riga::
612 Il corpo di una patch canonica contiene i seguenti elementi:
615 da una riga vuota (necessaria soltanto se la persona che invia la
643 una serie (dove una ``serie di patch`` è una sequenza ordinata di diverse
657 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
664 ci sono quelle di versione che vengono usate quando una patch è stata inviata
726 versione di una patch non sono parte del *chagelog* che viene incluso
774 potrebbe essere d'aiuto per associare una patch ad una discussione
778 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
781 ad una versione precedente di una serie di patch (per esempio, potete usarlo
811 E-mail di Linus Torvalds sul formato canonico di una patch: