Lines Matching refs:la
8 Inviare patch: la guida essenziale per vedere il vostro codice nel kernel
30 di ``git`` renderà la vostra vita di sviluppatore del kernel più facile.
48 Esiste ancora la possibilità di scaricare un rilascio del kernel come archivio
49 tar (come descritto in una delle prossime sezioni), ma questa è la via più
60 in :manpage:`diff(1)`. Quando create la vostra patch, assicuratevi di
63 Inoltre, per favore usate l'argomento ``-p`` per mostrare la funzione C
94 Assicuratevi che la vostra patch non includa file che non ne fanno veramente
95 parte. Al fine di verificarne la correttezza, assicuratevi anche di
96 revisionare la vostra patch -dopo- averla generata con :manpage:`diff(1)`.
100 :ref:`split_changes`. Questo faciliterà la revisione da parte degli altri
101 sviluppatori, il che è molto importante se volete che la patch venga accettata.
113 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
115 la pena risolvere il vostro problema e che ha senso continuare a leggere oltre
120 Anche se il problema è stato scoperto durante la revisione del codice,
122 la maggior parte delle installazioni Linux usa un kernel che arriva dai
132 o la dimensione del file binario, includete dei numeri a supporto della
135 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
141 nel dettaglio tecnico. È molto importante che descriviate la modifica
145 I manutentori vi saranno grati se scrivete la descrizione della patch in un
149 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
150 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
153 Quando inviate o rinviate una patch o una serie, includete la descrizione
154 completa delle modifiche e la loro giustificazione. Non limitatevi a dire che
155 questa è la versione N della patch (o serie). Non aspettatevi che i
157 cercare la descrizione da aggiungere. In pratica, la patch (o serie) e la sua
167 Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
168 il suo numero o il suo URL. Se la patch è la conseguenza di una discussione
174 Tuttavia, cercate di rendere la vostra spiegazione comprensibile anche senza
180 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
181 riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
191 questo rende possibile la collisione fra due identificativi con pochi
195 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
243 Se non potete condensare la vostra serie di patch in una più piccola, allora
251 Controllate che la vostra patch non violi lo stile del codice, maggiori
254 voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata
261 Questo aiuta enormemente la revisione delle vere differenze e permette agli
262 strumenti di tenere meglio la traccia della storia del codice.
287 (akpm@linux-foundation.org) sarà la vostra ultima possibilità.
290 la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
292 diversi sviluppatori non la seguano. Guardate nel file MAINTAINERS per trovare
293 la lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
313 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
314 in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
318 essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
333 nel file MAINTAINERS), o almeno una notifica circa la vostra modifica,
334 cosicché l'informazione possa trovare la sua strada nel manuale. Le modifiche
352 la modifica sia banale)
371 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
379 così la possibilità che il vostro allegato-MIME venga accettato.
392 per alcuni manutentori. Se la vostra patch, non compressa, eccede i 300 kB
394 l'URL (collegamento) ad essa. Ma notate che se la vostra patch eccede i 300 kB
401 la vostra patch. Dovete rispondere a questi commenti; ignorare i revisori
417 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
425 durante la finestra d'integrazione.
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
441 diversi livelli di manutentori, abbiamo introdotto la procedura di "firma"
455 ho il diritto di inviarlo in accordo con la licenza open-source
462 la licenza open-source (a meno che non abbia il permesso di usare
470 tutte le informazioni personali che invio con essi, inclusa la mia
484 per aggiungere dettagli circa la firma.
489 sorgenti e in quelli dei vostri contributori. Se rispettate rigidamente la
490 regola (c), dovreste chiedere al mittente di rifare la patch, ma questo è
493 la patch di qualcuno e addossargli la responsabilità per i vostri bachi.
495 Signed-off-by e il vostro, che spiega la vostra modifica. Nonostante non ci
508 circostanza è permessa la modifica dell'identità dell'autore (l'intestazione
513 patch all'inizio del messaggio di commit (appena dopo la riga dell'oggetto)
514 al fine di migliorare la tracciabilità. Per esempio, questo è quello che si
523 E qui quello che potrebbe vedersi su un kernel più vecchio dove la patch è
543 Se una persona non è direttamente coinvolta con la preparazione o gestione
544 della patch ma desidera firmare e mettere agli atti la loro approvazione,
549 quando quello stesso manutentore non ha contribuito né trasmesso la patch.
551 Acked-by: non è formale come Signed-off-by:. Questo indica che la persona ha
552 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
563 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
565 etichetta che può essere aggiunta senza che la persona in questione faccia
566 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
570 Co-developed-by: indica che la patch è stata cosviluppata da diversi
573 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
575 coautore. Qui si applica la procedura di base per sign-off, in pratica
578 la paternità venga assegnata via From: o Co-developed-by:. Da notare che
579 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
582 anche la persona (e indirizzo email) indicato nel From: dell'intestazione
615 L'etichetta Tested-by: indica che la patch è stata verificata con successo
621 Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
622 considerata accettabile in accordo con la dichiarazione dei revisori:
627 Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
633 (b) Tutti i problemi e le domande riguardanti la patch sono stati
642 (d) Nonostante abbia revisionato la patch e creda che vada bene,
647 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
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
654 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
664 L'etichetta Fixes: indica che la patch corregge un problema in un commit
665 precedente. Serve a chiarire l'origine di un baco, il che aiuta la revisione
667 kernel stabili al fine di capire quale kernel deve ricevere la correzione.
681 L'oggetto di una patch canonica è la riga::
688 da una riga vuota (necessaria soltanto se la persona che invia la
692 che verrà copiato permanentemente nel changelog per descrivere la patch.
715 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
719 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
723 cercare la ``summary phrase`` su internet per leggere le discussioni che la
736 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
750 La riga ``from`` dev'essere la prima nel corpo del messaggio ed è nel
756 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
757 l'autore da inserire nel changelog verrà usata la riga ``From``
765 i messaggi di log per la patch che li tratta. Se la patch corregge un errore
768 che la vostra patch venga trovata. Come nella ``summary phrase``, è importante
796 precedente, per esempio per collegare la correzione di un baco con l'e-mail
816 il manutentore avrà la possibilità di scegliere come integrarle.
836 che siate stati proprio voi a fare la richiesta. In assenza di tale etichetta
840 Il primo passo verso la creazione di questa etichetta firmata è quello di
844 essere un buon modo per trovare sviluppatori che possano firmare la vostra
847 Una volta che avete preparato la vostra serie di patch in ``git``, e volete che
850 contenente una firma creata con la vostra chiave privata. Avrete anche
870 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"