Lines Matching full:per
8 Inviare patch: la guida essenziale per vedere il vostro codice nel kernel
17 Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
20 Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
22 Per delle patch relative alle associazioni per Device Tree leggete
25 Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
37 ``git`` per ottenerli. Vorrete iniziare col repositorio principale che può
45 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
91 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
98 manutentori di un sottosistema vadano a cercare le versioni precedenti per
104 Descrivete le vostro modifiche usando l'imperativo, per esempio "make xyzzy
110 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
111 riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
112 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
113 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
119 servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
121 messaggio, senza parentesi angolari. Per esempio::
133 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
134 riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
135 Per esempio::
148 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
149 trovato un problema usando ``git bisect``, per favore usate l'etichetta
151 dalla riga riassuntiva. Per esempio::
155 La seguente configurazione di ``git config`` può essere usata per formattare
176 Per esempio, se i vostri cambiamenti per un singolo driver includono
188 Ogni patch dovrebbe essere giustificabile di per sé.
191 va bene. Semplicemente scrivete una nota nella descrizione della patch per
195 particolare attenzione alla verifica di ogni patch della serie; per ognuna
197 che usano ``git bisect`` per scovare i problemi potrebbero finire nel mezzo
217 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
242 delle revisioni per scoprire chi si occupa del codice. Lo script
244 vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
250 dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
251 diversi sviluppatori la trascurano. Guardate nel file MAINTAINERS per trovare la
253 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
267 meglio per -evitare di- inviargli e-mail.
270 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
271 embargo potrebbe essere preso in considerazione per dare il tempo alle
286 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
287 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
297 le modifiche che sottomettete. Per uno sviluppatore è importante
302 Per questa ragione tutte le patch devono essere inviate via e-mail
325 per dei suggerimenti sulla configurazione del programmi di posta elettronica
326 per l'invio di patch intatte.
333 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
340 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
348 Leggete Documentation/translations/it_IT/process/email-clients.rst per
381 Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
392 Per migliorare la tracciabilità su "chi ha fatto cosa", specialmente per
393 quelle patch che per raggiungere lo stadio finale passano attraverso
395 delle patch che vengono inviate per e-mail.
438 Alcune persone aggiungono delle etichette alla fine. Per ora queste verranno
439 ignorate, ma potete farlo per meglio identificare procedure aziendali interne o
440 per aggiungere dettagli circa la firma.
447 manutentore, per poi giungere a Linus.
465 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
469 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
484 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
488 coautore. Qui si applica la procedura di base per sign-off, in pratica
527 usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
531 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
533 stesse persone ricevano credito per il loro lavoro.
543 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
553 di interesse per il kernel, e (2) libera da problemi che
564 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
567 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
587 del baco stesso. Questa etichetta è di aiuto anche per i manutentori dei
589 Questo è il modo suggerito per indicare che un baco è stato corretto nella
590 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
593 previste per i kernel stabili, e nemmeno dalla necessità di aggiungere
594 in copia conoscenza stable@vger.kernel.org su tutte le patch per
602 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
603 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
604 potere usare il comando ``git format-patch`` per ottenere patch nel formato
605 appropriato. Lo strumento non crea il testo necessario, per cui, leggete
619 che verrà copiato permanentemente nel changelog per descrivere la patch.
632 Il formato usato per l'oggetto permette ai programmi di posta di usarlo
633 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
642 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
647 identificatore globale ed unico per quella patch. Si propaga fino al
649 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
650 cercare la ``summary phrase`` su internet per leggere le discussioni che la
655 Per queste ragioni, dovrebbe essere lunga fra i 70 e i 75 caratteri, e deve
665 più volte (per esempio, "v1, v2, v3"); oppure "RFC" per indicare che si
671 applicate, e per tracciare quelle che hanno revisionate o che hanno
687 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
691 Il corpo della spiegazione verrà incluso nel changelog permanente, per cui
692 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
695 eccetera) è particolarmente utile per le persone che potrebbero cercare fra
696 i messaggi di log per la patch che li tratta. Il testo dovrebbe essere scritto
703 aggiungete solo quello che è necessario per far si che la vostra patch
710 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
712 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
718 I commenti che sono importanti solo per i manutentori, quindi
720 buon esempio per questo tipo di commenti potrebbe essere il cosiddetto
728 messe sopra la riga, qualcuno dovrà fare del lavoro manuale per
751 davvero utili. Per esempio, le sequenze iniziali di avvio sono uniche
753 informazioni che distraggono dal vero problema (per esempio, i
757 Quindi, per rendere utile un *backtrace* dovreste eliminare le
774 potrebbe essere d'aiuto per associare una patch ad una discussione
775 precedente, per esempio per collegare la correzione di un baco con l'e-mail
776 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
777 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
780 è utile, potete usare https://lore.kernel.org/ per ottenere i collegamenti
781 ad una versione precedente di una serie di patch (per esempio, potete usarlo
782 per l'email introduttiva alla serie).
790 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"