xref: /linux/Documentation/translations/it_IT/doc-guide/maintainer-profile.rst (revision 72fdff1416e280e2baaa3cca69574defb998437e)
1.. SPDX-License-Identifier: GPL-2.0
2
3.. include:: ../disclaimer-ita.rst
4
5Profilo del manutentore del sottosistema di documentazione
6==========================================================
7
8Il "sottosistema" della documentazione è il punto di coordinamento
9centrale per la documentazione del kernel e la relativa infrastruttura.
10Copre la gerarchia sotto Documentation/ (con l'eccezione di
11Documentation/devicetree), diverse utilità sotto scripts/ e, almeno in
12parte, LICENSES/.
13
14Vale la pena notare, però, che i confini di questo sottosistema sono più sfumati
15del normale. Molti altri manutentori di sottosistemi preferiscono mantenere il
16controllo di alcune parti di Documentation/, e molti altri ancora vi applicano
17liberamente delle modifiche quando è conveniente. Oltre a ciò, buona parte della
18documentazione del kernel si trova nel codice sorgente sotto forma di commenti
19kerneldoc; questi sono solitamente (ma non sempre) mantenuti dal manutentore del
20sottosistema pertinente.
21
22La lista di discussione per la documentazione è linux-doc@vger.kernel.org.
23Le patch dovrebbero essere inviate contro l'albero docs-next quando
24possibile.
25
26Aggiunta alla checklist di invio
27--------------------------------
28
29Quando si apportano modifiche alla documentazione, dovreste generare
30effettivamente la documentazione e assicurarvi che non siano stati
31introdotti nuovi errori o avvisi. Generare i documenti in HTML e osservare
32il risultato aiuterà a evitare fraintendimenti spiacevoli su come le cose
33verranno rappresentate.
34
35Tutta la nuova documentazione (incluse le aggiunte a documenti esistenti)
36dovrebbe idealmente giustificare, da qualche parte nel changelog, chi sia
37il pubblico a cui è destinata; in questo modo, ci assicuriamo che la
38documentazione finisca nel posto giusto. Alcune categorie possibili
39sono: sviluppatori del kernel (esperti o principianti), programmatori
40dello spazio utente, utenti finali e/o amministratori di sistema, e
41distributori.
42
43Date chiave del ciclo
44---------------------
45
46Le patch possono essere inviate in qualsiasi momento, ma la risposta sarà
47più lenta del solito durante la finestra d'integrazione. L'albero della
48documentazione tende a chiudersi tardi, prima dell'apertura della finestra
49d'integrazione, poiché il rischio di regressioni dovute a patch sulla
50documentazione è basso.
51
52Cadenza di revisione
53--------------------
54
55Sono (Jonathan Corbet) l'unico manutentore del sottosistema di documentazione, e
56svolgo questo lavoro nel mio tempo libero, quindi la risposta alle patch sarà a
57volte lenta. Cerco sempre di inviare una notifica quando una patch viene
58integrata (o quando decido che non può esserlo). Non esitate a inviare un
59sollecito se non avete ricevuto risposta entro una settimana dall'invio di una
60patch.
61