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 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
111 riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
112 Per esempio::
126 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
131 Per esempio, se la vostra patch corregge un baco potete aggiungere
132 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
133 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
139 servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
141 messaggio, senza parentesi angolari. Per esempio::
163 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
164 trovato un problema usando ``git bisect``, per favore usate l'etichetta
166 dalla riga riassuntiva. Per esempio::
170 La seguente configurazione di ``git config`` può essere usata per formattare
191 Per esempio, se i vostri cambiamenti per un singolo driver includono
203 Ogni patch dovrebbe essere giustificabile di per sé.
206 va bene. Semplicemente scrivete una nota nella descrizione della patch per
210 particolare attenzione alla verifica di ogni patch della serie; per ognuna
212 che usano ``git bisect`` per scovare i problemi potrebbero finire nel mezzo
232 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
257 file MAINTAINERS e alla storia delle revisioni per scoprire chi si occupa del
259 percorso alle vostre patch). Se non riuscite a trovare un manutentore per il
263 La lista [email protected] dovrebbe essere usata per l'invio di tutte
265 sviluppatori a non seguirla più. Dunque, per favore, evitate di inviare messaggi
271 dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
272 diversi sviluppatori la trascurano. Guardate nel file MAINTAINERS per trovare la
274 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
286 meglio per -evitare di- inviargli e-mail.
289 sfruttato, inviatela a [email protected]. Per bachi importanti, un breve
290 embargo potrebbe essere preso in considerazione per dare il tempo alle
305 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
306 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
316 le modifiche che sottomettete. Per uno sviluppatore è importante
321 Per questa ragione tutte le patch devono essere inviate via e-mail
344 per dei suggerimenti sulla configurazione del programmi di posta elettronica
345 per l'invio di patch intatte.
352 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
359 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
366 vi hanno fornito dei commenti per notificarle di eventuali nuove versioni.
368 Leggete Documentation/translations/it_IT/process/email-clients.rst per
391 Allo stesso modo, per favore eliminate tutte le citazioni non necessarie per la
393 permette di risparmiare tempo e spazio. Per maggiori dettagli:
428 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.
485 Alcune persone aggiungono delle etichette alla fine. Per ora queste verranno
486 ignorate, ma potete farlo per meglio identificare procedure aziendali interne o
487 per aggiungere dettagli circa la firma.
494 manutentore, per poi giungere a Linus.
512 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
516 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
531 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
535 coautore. Qui si applica la procedura di base per sign-off, in pratica
574 usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
582 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
584 stesse persone ricevano credito per il loro lavoro.
594 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
604 di interesse per il kernel, e (2) libera da problemi che
615 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
618 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
638 del baco stesso. Questa etichetta è di aiuto anche per i manutentori dei
640 Questo è il modo suggerito per indicare che un baco è stato corretto nella
641 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
644 previste per i kernel stabili, e nemmeno dalla necessità di aggiungere
645 in copia conoscenza [email protected] su tutte le patch per
653 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
654 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
655 potere usare il comando ``git format-patch`` per ottenere patch nel formato
656 appropriato. Lo strumento non crea il testo necessario, per cui, leggete
670 che verrà copiato permanentemente nel changelog per descrivere la patch.
683 Il formato usato per l'oggetto permette ai programmi di posta di usarlo
684 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
693 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
698 identificatore globale ed unico per quella patch. Si propaga fino al
700 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
701 cercare la ``summary phrase`` su internet per leggere le discussioni che la
706 Per queste ragioni, dovrebbe essere lunga fra i 70 e i 75 caratteri, e deve
716 più volte (per esempio, "v1, v2, v3"); oppure "RFC" per indicare che si
722 applicate, e per tracciare quelle che hanno revisionate o che hanno
738 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
742 Il corpo della spiegazione verrà incluso nel changelog permanente, per cui
743 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
746 eccetera) è particolarmente utile per le persone che potrebbero cercare fra
747 i messaggi di log per la patch che li tratta. Il testo dovrebbe essere scritto
754 aggiungete solo quello che è necessario per far si che la vostra patch
761 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
763 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
769 I commenti che sono importanti solo per i manutentori, quindi
771 buon esempio per questo tipo di commenti potrebbe essere il cosiddetto
779 messe sopra la riga, qualcuno dovrà fare del lavoro manuale per
802 davvero utili. Per esempio, le sequenze iniziali di avvio sono uniche
804 informazioni che distraggono dal vero problema (per esempio, i
808 Quindi, per rendere utile un *backtrace* dovreste eliminare le
825 potrebbe essere d'aiuto per associare una patch ad una discussione
826 precedente, per esempio per collegare la correzione di un baco con l'e-mail
827 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
828 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
831 è utile, potete usare https://lore.kernel.org/ per ottenere i collegamenti
832 ad una versione precedente di una serie di patch (per esempio, potete usarlo
833 per l'email introduttiva alla serie).
844 Questo è ancora più importante per i processi automatizzati di CI che tentano di
845 eseguire una serie di test per stabilire la qualità del codice prima che il
848 Se si usa ``git format-patch`` per generare le patch, si possono includere
864 Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà
866 strumenti CI informazioni sufficienti per eseguire correttamente ``git am``
875 Consultate ``man git-format-patch`` per maggiori informazioni circa questa
882 Se non si usa git per produrre le patch, si può comunque includere
883 ``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il
906 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"