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
21 per una lista di punti da verificare prima di inviare del codice. Se state
23 per delle patch relative alle associazioni per Device Tree leggete
27 controllo di versione ``git``; se utilizzate ``git`` per preparare le vostre
28 patch molto del lavoro più ripetitivo lo troverete già fatto per voi, tuttavia
36 ``git`` per ottenerli. Vorrete iniziare col repositorio principale che può
44 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
50 complicata per sviluppare per il kernel.
56 per crearle. Git produce di base le patch in questo formato; se state
63 Inoltre, per favore usate l'argomento ``-p`` per mostrare la funzione C
68 Per creare una patch per un singolo file, spesso è sufficiente fare::
79 Per creare una patch per molteplici file, dovreste spacchettare i sorgenti
81 Per esempio::
149 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
156 manutentori di un sottosistema vadano a cercare le versioni precedenti per
162 Descrivete le vostro modifiche usando l'imperativo, per esempio "make xyzzy
180 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
181 riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
182 Per esempio::
195 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
196 trovato un problema usando ``git bisect``, per favore usate l'etichetta
198 dalla riga riassuntiva. Per esempio::
202 La seguente configurazione di ``git config`` può essere usata per formattare
218 Per esempio, se i vostri cambiamenti per un singolo driver includono
230 Ogni patch dovrebbe essere giustificabile di per sé.
233 va bene. Semplicemente scrivete una nota nella descrizione della patch per
237 particolare attenzione alla verifica di ogni patch della serie; per ognuna
239 che usano ``git bisect`` per scovare i problemi potrebbero finire nel mezzo
259 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
284 delle revisioni per scoprire chi si occupa del codice. Lo script
286 manutentore per il sottosistema su cui state lavorando, allora Andrew Morton
292 diversi sviluppatori non la seguano. Guardate nel file MAINTAINERS per trovare
294 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le
308 meglio per -evitare di- inviargli e-mail.
311 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
312 embargo potrebbe essere preso in considerazione per dare il tempo alle
331 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
332 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
338 Per le piccole patch potreste aggiungere in CC l'indirizzo
340 le patch "banali". Date uno sguardo al file MAINTAINERS per vedere chi
351 specifico per un'architettura, dato che le persone copiano, fintanto che
361 le modifiche che sottomettete. Per uno sviluppatore è importante
366 Per questa ragione tutte le patch devono essere inviate via e-mail
385 per dei suggerimenti sulla configurazione del programmi di posta elettronica
386 per l'invio di patch intatte.
392 per alcuni manutentori. Se la vostra patch, non compressa, eccede i 300 kB
402 è un ottimo modo per essere ignorati. Riscontri o domande che non conducono
408 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
430 Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
439 Per migliorare la tracciabilità su "chi ha fatto cosa", specialmente per
440 quelle patch che per raggiungere lo stadio finale passano attraverso
442 delle patch che vengono inviate per e-mail.
482 Alcune persone aggiungono delle etichette alla fine. Per ora queste verranno
483 ignorate, ma potete farlo per meglio identificare procedure aziendali interne o
484 per aggiungere dettagli circa la firma.
493 la patch di qualcuno e addossargli la responsabilità per i vostri bachi.
494 Per risolvere questo problema dovreste aggiungere una riga, fra l'ultimo
498 questo renderà abbastanza visibile chi è responsabile per le modifiche
499 dell'ultimo minuto. Per esempio::
511 Un appunto speciale per chi porta il codice su vecchie versioni. Sembra che
514 al fine di migliorare la tracciabilità. Per esempio, questo è quello che si
552 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
556 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
571 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
575 coautore. Qui si applica la procedura di base per sign-off, in pratica
617 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
619 stesse persone ricevano credito per il loro lavoro.
629 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
639 di interesse per il kernel, e (2) libera da problemi che
650 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
653 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
666 del baco stesso. Questa etichetta è di aiuto anche per i manutentori dei
668 Questo è il modo suggerito per indicare che un baco è stato corretto nella
669 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
675 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
676 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
677 potere usare il comando ``git format-patch`` per ottenere patch nel formato
678 appropriato. Lo strumento non crea il testo necessario, per cui, leggete
692 che verrà copiato permanentemente nel changelog per descrivere la patch.
705 Il formato usato per l'oggetto permette ai programmi di posta di usarlo
706 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
715 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
720 identificatore globale ed unico per quella patch. Si propaga fino al
722 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
723 cercare la ``summary phrase`` su internet per leggere le discussioni che la
728 Per queste ragioni, dovrebbe essere lunga fra i 70 e i 75 caratteri, e deve
738 più volte (per esempio, "v1, v2, v3"); oppure "RFC" per indicare che si
742 dovrebbero essere applicate, e per tracciare quelle che hanno revisionate o
756 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
760 Il corpo della spiegazione verrà incluso nel changelog permanente, per cui
761 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
764 eccetera) è particolarmente utile per le persone che potrebbero cercare fra
765 i messaggi di log per la patch che li tratta. Se la patch corregge un errore
767 è uscito dal compilatore; aggiungete solo quello che è necessario per far si
774 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
776 Un ``diffstat`` è particolarmente utile per le patch grandi. Altri commenti
777 che sono importanti solo per i manutentori, quindi inadatti al changelog
778 permanente, dovrebbero essere messi qui. Un buon esempio per questo tipo
795 potrebbe essere d'aiuto per associare una patch ad una discussione
796 precedente, per esempio per collegare la correzione di un baco con l'e-mail
797 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
798 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
801 è utile, potete usare https://lkml.kernel.org/ per ottenere i collegamenti
802 ad una versione precedente di una serie di patch (per esempio, potete usarlo
803 per l'email introduttiva alla serie).
808 Se avete una serie di patch, potrebbe essere più conveniente per un manutentore
831 semplice per ottenere tutte queste informazioni è, ovviamente, quello di
842 principali del kernel. Questo potrebbe essere difficile per i nuovi
844 essere un buon modo per trovare sviluppatori che possano firmare la vostra
852 il posto ideale per descrivere gli effetti della richiesta di *pull*.
870 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"