Documentation/translations/it_IT/process/3.Early-stage.rst

   1 .. include:: ../disclaimer-ita.rst
   2
   3 :Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
   4 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
   5
   6 .. _it_development_early_stage:
   7
   8 I primi passi della pianificazione
   9 ==================================
  10
  11 Osservando un progetto di sviluppo per il kernel Linux, si potrebbe essere
  12 tentati dal saltare tutto e iniziare a codificare.  Tuttavia, come ogni
  13 progetto significativo, molta della preparazione per giungere al successo
  14 viene fatta prima che una sola linea di codice venga scritta.  Il tempo speso
  15 nella pianificazione e la comunicazione può far risparmiare molto
  16 tempo in futuro.
  17
  18 Specificare il problema
  19 -----------------------
  20
  21 Come qualsiasi progetto ingegneristico, un miglioramento del kernel di
  22 successo parte con una chiara descrizione del problema da risolvere.
  23 In alcuni casi, questo passaggio è facile: ad esempio quando un driver è
  24 richiesto per un particolare dispositivo.  In altri casi invece, si
  25 tende a confondere il problema reale con le soluzioni proposte e questo
  26 può portare all'emergere di problemi.
  27
  28 Facciamo un esempio: qualche anno fa, gli sviluppatori che lavoravano con
  29 linux audio cercarono un modo per far girare le applicazioni senza dropouts
  30 o altri artefatti dovuti all'eccessivo ritardo nel sistema.  La soluzione
  31 alla quale giunsero fu un modulo del kernel destinato ad agganciarsi al
  32 framework Linux Security Module (LSM); questo modulo poteva essere
  33 configurato per dare ad una specifica applicazione accesso allo
  34 schedulatore *realtime*.  Tale modulo fu implementato e inviato nella
  35 lista di discussione linux-kernel, dove incontrò subito dei problemi.
  36
  37 Per gli sviluppatori audio, questo modulo di sicurezza era sufficiente a
  38 risolvere il loro problema nell'immediato.  Per l'intera comunità kernel,
  39 invece, era un uso improprio del framework LSM (che non è progettato per
  40 conferire privilegi a processi che altrimenti non avrebbero potuto ottenerli)
  41 e un rischio per la stabilità del sistema.  Le loro soluzioni di punta nel
  42 breve periodo, comportavano un accesso alla schedulazione realtime attraverso
  43 il meccanismo rlimit, e nel lungo periodo un costante lavoro nella riduzione
  44 dei ritardi.
  45
  46 La comunità audio, comunque, non poteva vedere al di là della singola
  47 soluzione che avevano implementato; erano riluttanti ad accettare alternative.
  48 Il conseguente dissenso lasciò in quegli sviluppatori un senso di
  49 disillusione nei confronti dell'intero processo di sviluppo; uno di loro
  50 scrisse questo messaggio:
  51
  52         Ci sono numerosi sviluppatori del kernel Linux davvero bravi, ma
  53         rischiano di restare sovrastati da una vasta massa di stolti arroganti.
  54         Cercare di comunicare le richieste degli utenti a queste persone è
  55         una perdita di tempo. Loro sono troppo "intelligenti" per stare ad
  56         ascoltare dei poveri mortali.
  57
  58         (http://lwn.net/Articles/131776/).
  59
  60 La realtà delle cose fu differente; gli sviluppatori del kernel erano molto
  61 più preoccupati per la stabilità del sistema, per la manutenzione di lungo
  62 periodo e cercavano la giusta soluzione alla problematica esistente con uno
  63 specifico modulo.  La morale della storia è quella di concentrarsi sul
  64 problema - non su di una specifica soluzione- e di discuterne con la comunità
  65 di sviluppo prima di investire tempo nella scrittura del codice.
  66
  67 Quindi, osservando un progetto di sviluppo del kernel, si dovrebbe
  68 rispondere a questa lista di domande:
  69
  70 - Qual'è, precisamente, il problema che dev'essere risolto?
  71
  72 - Chi sono gli utenti coinvolti da tal problema? A quale caso dovrebbe
  73   essere indirizzata la soluzione?
  74
  75 - In che modo il kernel risulta manchevole nell'indirizzare il problema
  76   in questione?
  77
  78 Solo dopo ha senso iniziare a considerare le possibili soluzioni.
  79
  80 Prime discussioni
  81 -----------------
  82
  83 Quando si pianifica un progetto di sviluppo per il kernel, sarebbe quanto meno
  84 opportuno discuterne inizialmente con la comunità prima di lanciarsi
  85 nell'implementazione.  Una discussione preliminare può far risparmiare sia
  86 tempo che problemi in svariati modi:
  87
  88  - Potrebbe essere che il problema sia già stato risolto nel kernel in
  89    una maniera che non avete ancora compreso.  Il kernel Linux è grande e ha
  90    una serie di funzionalità e capacità che non sono scontate nell'immediato.
  91    Non tutte le capacità del kernel sono documentate così bene come ci
  92    piacerebbe, ed è facile perdersi qualcosa.  Il vostro autore ha assistito
  93    alla pubblicazione di un driver intero che duplica un altro driver
  94    esistente di cui il nuovo autore era ignaro.  Il codice che rinnova
  95    ingranaggi già esistenti non è soltanto dispendioso; non verrà nemmeno
  96    accettato nel ramo principale del kernel.
  97
  98  - Potrebbero esserci proposte che non sono considerate accettabili per
  99    l'integrazione all'interno del ramo principale. È meglio affrontarle
 100    prima di scrivere il codice.
 101
 102  - È possibile che altri sviluppatori abbiano pensato al problema; potrebbero
 103    avere delle idee per soluzioni migliori, e potrebbero voler contribuire
 104    alla loro creazione.
 105
 106 Anni di esperienza con la comunità di sviluppo del kernel hanno impartito una
 107 chiara lezione: il codice per il kernel che è pensato e sviluppato a porte
 108 chiuse, inevitabilmente, ha problematiche che si rivelano solo quando il
 109 codice viene rilasciato pubblicamente.  Qualche volta tali problemi sono
 110 importanti e richiedono mesi o anni di sforzi prima che il codice possa
 111 raggiungere gli standard richiesti della comunità.
 112 Alcuni esempi possono essere:
 113
 114  - La rete Devicescape è stata creata e implementata per sistemi
 115    mono-processore.  Non avrebbe potuto essere inserita nel ramo principale
 116    fino a che non avesse supportato anche i sistemi multi-processore.
 117    Riadattare i meccanismi di sincronizzazione e simili è un compito difficile;
 118    come risultato, l'inserimento di questo codice (ora chiamato mac80211)
 119    fu rimandato per più di un anno.
 120
 121  - Il filesystem Reiser4 include una seria di funzionalità che, secondo
 122    l'opinione degli sviluppatori principali del kernel, avrebbero dovuto
 123    essere implementate a livello di filesystem virtuale.  Comprende
 124    anche funzionalità che non sono facilmente implementabili senza esporre
 125    il sistema al rischio di uno stallo.  La scoperta tardiva di questi
 126    problemi - e il diniego a risolverne alcuni - ha avuto come conseguenza
 127    il fatto che Raiser4 resta fuori dal ramo principale del kernel.
 128
 129  - Il modulo di sicurezza AppArmor utilizzava strutture dati del
 130    filesystem virtuale interno in modi che sono stati considerati rischiosi e
 131    inattendibili.  Questi problemi (tra le altre cose) hanno tenuto AppArmor
 132    fuori dal ramo principale per anni.
 133
 134 Ciascuno di questi casi è stato un travaglio e ha richiesto del lavoro
 135 straordinario, cose che avrebbero potuto essere evitate con alcune
 136 "chiacchierate" preliminari con gli sviluppatori kernel.
 137
 138 Con chi parlare?
 139 ----------------
 140
 141 Quando gli sviluppatori hanno deciso di rendere pubblici i propri progetti, la
 142 domanda successiva sarà: da dove partiamo?  La risposta è quella di trovare
 143 la giusta lista di discussione e il giusto manutentore.  Per le liste di
 144 discussione, il miglior approccio è quello di cercare la lista più adatta
 145 nel file MAINTAINERS.  Se esiste una lista di discussione di sottosistema,
 146 è preferibile pubblicare lì piuttosto che sulla lista di discussione generale
 147 del kernel Linux; avrete maggiori probabilità di trovare sviluppatori con
 148 esperienza sul tema, e l'ambiente che troverete potrebbe essere più
 149 incoraggiante.
 150
 151 Trovare manutentori può rivelarsi un po' difficoltoso.  Ancora, il file
 152 MAINTAINERS è il posto giusto da dove iniziare.  Il file potrebbe non essere
 153 sempre aggiornato, inoltre, non tutti i sottosistemi sono rappresentati qui.
 154 Coloro che sono elencati nel file MAINTAINERS potrebbero, in effetti, non
 155 essere le persone che attualmente svolgono quel determinato ruolo.  Quindi,
 156 quando c'è un dubbio su chi contattare, un trucco utile è quello di usare
 157 git (git log in particolare) per vedere chi attualmente è attivo all'interno
 158 del sottosistema interessato.  Controllate chi sta scrivendo le patch,
 159 e chi, se non ci fosse nessuno, sta aggiungendo la propria firma
 160 (Signed-off-by) a quelle patch.  Quelle sono le persone maggiormente
 161 qualificate per aiutarvi con lo sviluppo di nuovo progetto.
 162
 163 Il compito di trovare il giusto manutentore, a volte, è una tale sfida che
 164 ha spinto gli sviluppatori del kernel a scrivere uno script che li aiutasse
 165 in questa ricerca:
 166
 167 ::
 168
 169         .../scripts/get_maintainer.pl
 170
 171 Se questo script viene eseguito con l'opzione "-f" ritornerà il
 172 manutentore(i) attuale per un dato file o cartella.  Se viene passata una
 173 patch sulla linea di comando, lo script elencherà i manutentori che
 174 dovrebbero riceverne una copia.  Ci sono svariate opzioni che regolano
 175 quanto a fondo get_maintainer.pl debba cercare i manutentori;
 176 siate quindi prudenti nell'utilizzare le opzioni più aggressive poiché
 177 potreste finire per includere sviluppatori che non hanno un vero interesse
 178 per il codice che state modificando.
 179
 180 Se tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere
 181 un modo efficace per capire chi è il manutentore di un dato pezzo di codice.
 182
 183 Quando pubblicare
 184 -----------------
 185
 186 Se potete, pubblicate i vostri intenti durante le fasi preliminari, sarà
 187 molto utile.  Descrivete il problema da risolvere e ogni piano che è stato
 188 elaborato per l'implementazione.  Ogni informazione fornita può aiutare
 189 la comunità di sviluppo a fornire spunti utili per il progetto.
 190
 191 Un evento che potrebbe risultare scoraggiate e che potrebbe accadere in
 192 questa fase non è il ricevere una risposta ostile, ma, invece, ottenere
 193 una misera o inesistente reazione.  La triste verità è che: (1) gli
 194 sviluppatori del kernel tendono ad essere occupati, (2) ci sono tante persone
 195 con grandi progetti e poco codice (o anche solo la prospettiva di
 196 avere un codice) a cui riferirsi e (3) nessuno è obbligato a revisionare
 197 o a fare osservazioni in merito ad idee pubblicate da altri.  Oltre a
 198 questo, progetti di alto livello spesso nascondono problematiche che si
 199 rivelano solo quando qualcuno cerca di implementarle; per questa ragione
 200 gli sviluppatori kernel preferirebbero vedere il codice.
 201
 202 Quindi, se una richiesta pubblica di commenti riscuote poco successo, non
 203 pensate che ciò significhi che non ci sia interesse nel progetto.
 204 Sfortunatamente, non potete nemmeno assumere che non ci siano problemi con
 205 la vostra idea.  La cosa migliore da fare in questa situazione è quella di
 206 andare avanti e tenere la comunità informata mentre procedete.
 207
 208 Ottenere riscontri ufficiali
 209 ----------------------------
 210
 211 Se il vostro lavoro è stato svolto in un ambiente aziendale - come molto
 212 del lavoro fatto su Linux - dovete, ovviamente, avere il permesso dei
 213 dirigenti prima che possiate pubblicare i progetti, o il codice aziendale,
 214 su una lista di discussione pubblica.  La pubblicazione di codice che non
 215 è stato rilascio espressamente con licenza GPL-compatibile può rivelarsi
 216 problematico; prima la dirigenza, e il personale legale, troverà una decisione
 217 sulla pubblicazione di un progetto, meglio sarà per tutte le persone coinvolte.
 218
 219 A questo punto, alcuni lettori potrebbero pensare che il loro lavoro sul
 220 kernel è preposto a supportare un prodotto che non è ancora ufficialmente
 221 riconosciuto.  Rivelare le intenzioni dei propri datori di lavori in una
 222 lista di discussione pubblica potrebbe non essere una soluzione valida.
 223 In questi casi, vale la pena considerare se la segretezza sia necessaria
 224 o meno; spesso non c'è una reale necessità di mantenere chiusi i progetti di
 225 sviluppo.
 226
 227 Detto ciò, ci sono anche casi dove l'azienda legittimamente non può rivelare
 228 le proprie intenzioni in anticipo durante il processo di sviluppo.  Le aziende
 229 che hanno sviluppatori kernel esperti possono scegliere di procedere a
 230 carte coperte partendo dall'assunto che saranno in grado di evitare, o gestire,
 231 in futuro, eventuali problemi d'integrazione. Per le aziende senza questo tipo
 232 di esperti, la migliore opzione è spesso quella di assumere uno sviluppatore
 233 esterno che revisioni i progetti con un accordo di segretezza.
 234 La Linux Foundation applica un programma di NDA creato appositamente per
 235 aiutare le aziende in questa particolare situazione; potrete trovare più
 236 informazioni sul sito:
 237
 238     http://www.linuxfoundation.org/en/NDA_program
 239
 240 Questa tipologia di revisione è spesso sufficiente per evitare gravi problemi
 241 senza che sia richiesta l'esposizione pubblica del progetto.