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 8I primi passi della pianificazione 9================================== 10 11Osservando un progetto di sviluppo per il kernel Linux, si potrebbe essere 12tentati dal saltare tutto e iniziare a codificare. Tuttavia, come ogni 13progetto significativo, molta della preparazione per giungere al successo 14viene fatta prima che una sola linea di codice venga scritta. Il tempo speso 15nella pianificazione e la comunicazione pu�� far risparmiare molto 16tempo in futuro. 17 18Specificare il problema 19----------------------- 20 21Come qualsiasi progetto ingegneristico, un miglioramento del kernel di 22successo parte con una chiara descrizione del problema da risolvere. 23In alcuni casi, questo passaggio �� facile: ad esempio quando un driver �� 24richiesto per un particolare dispositivo. In altri casi invece, si 25tende a confondere il problema reale con le soluzioni proposte e questo 26pu�� portare all'emergere di problemi. 27 28Facciamo un esempio: qualche anno fa, gli sviluppatori che lavoravano con 29linux audio cercarono un modo per far girare le applicazioni senza dropouts 30o altri artefatti dovuti all'eccessivo ritardo nel sistema. La soluzione 31alla quale giunsero fu un modulo del kernel destinato ad agganciarsi al 32framework Linux Security Module (LSM); questo modulo poteva essere 33configurato per dare ad una specifica applicazione accesso allo 34schedulatore *realtime*. Tale modulo fu implementato e inviato nella 35lista di discussione linux-kernel, dove incontr�� subito dei problemi. 36 37Per gli sviluppatori audio, questo modulo di sicurezza era sufficiente a 38risolvere il loro problema nell'immediato. Per l'intera comunit�� kernel, 39invece, era un uso improprio del framework LSM (che non �� progettato per 40conferire privilegi a processi che altrimenti non avrebbero potuto ottenerli) 41e un rischio per la stabilit�� del sistema. Le loro soluzioni di punta nel 42breve periodo, comportavano un accesso alla schedulazione realtime attraverso 43il meccanismo rlimit, e nel lungo periodo un costante lavoro nella riduzione 44dei ritardi. 45 46La comunit�� audio, comunque, non poteva vedere al di l�� della singola 47soluzione che avevano implementato; erano riluttanti ad accettare alternative. 48Il conseguente dissenso lasci�� in quegli sviluppatori un senso di 49disillusione nei confronti dell'intero processo di sviluppo; uno di loro 50scrisse 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 60La realt�� delle cose fu differente; gli sviluppatori del kernel erano molto 61pi�� preoccupati per la stabilit�� del sistema, per la manutenzione di lungo 62periodo e cercavano la giusta soluzione alla problematica esistente con uno 63specifico modulo. La morale della storia �� quella di concentrarsi sul 64problema - non su di una specifica soluzione- e di discuterne con la comunit�� 65di sviluppo prima di investire tempo nella scrittura del codice. 66 67Quindi, osservando un progetto di sviluppo del kernel, si dovrebbe 68rispondere 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 78Solo dopo ha senso iniziare a considerare le possibili soluzioni. 79 80Prime discussioni 81----------------- 82 83Quando si pianifica un progetto di sviluppo per il kernel, sarebbe quanto meno 84opportuno discuterne inizialmente con la comunit�� prima di lanciarsi 85nell'implementazione. Una discussione preliminare pu�� far risparmiare sia 86tempo 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 106Anni di esperienza con la comunit�� di sviluppo del kernel hanno impartito una 107chiara lezione: il codice per il kernel che �� pensato e sviluppato a porte 108chiuse, inevitabilmente, ha problematiche che si rivelano solo quando il 109codice viene rilasciato pubblicamente. Qualche volta tali problemi sono 110importanti e richiedono mesi o anni di sforzi prima che il codice possa 111raggiungere gli standard richiesti della comunit��. 112Alcuni 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 134Ciascuno di questi casi �� stato un travaglio e ha richiesto del lavoro 135straordinario, cose che avrebbero potuto essere evitate con alcune 136"chiacchierate" preliminari con gli sviluppatori kernel. 137 138Con chi parlare? 139---------------- 140 141Quando gli sviluppatori hanno deciso di rendere pubblici i propri progetti, la 142domanda successiva sar��: da dove partiamo? La risposta �� quella di trovare 143la giusta lista di discussione e il giusto manutentore. Per le liste di 144discussione, il miglior approccio �� quello di cercare la lista pi�� adatta 145nel file MAINTAINERS. Se esiste una lista di discussione di sottosistema, 146�� preferibile pubblicare l�� piuttosto che sulla lista di discussione generale 147del kernel Linux; avrete maggiori probabilit�� di trovare sviluppatori con 148esperienza sul tema, e l'ambiente che troverete potrebbe essere pi�� 149incoraggiante. 150 151Trovare manutentori pu�� rivelarsi un po' difficoltoso. Ancora, il file 152MAINTAINERS �� il posto giusto da dove iniziare. Il file potrebbe non essere 153sempre aggiornato, inoltre, non tutti i sottosistemi sono rappresentati qui. 154Coloro che sono elencati nel file MAINTAINERS potrebbero, in effetti, non 155essere le persone che attualmente svolgono quel determinato ruolo. Quindi, 156quando c'�� un dubbio su chi contattare, un trucco utile �� quello di usare 157git (git log in particolare) per vedere chi attualmente �� attivo all'interno 158del sottosistema interessato. Controllate chi sta scrivendo le patch, 159e chi, se non ci fosse nessuno, sta aggiungendo la propria firma 160(Signed-off-by) a quelle patch. Quelle sono le persone maggiormente 161qualificate per aiutarvi con lo sviluppo di nuovo progetto. 162 163Il compito di trovare il giusto manutentore, a volte, �� una tale sfida che 164ha spinto gli sviluppatori del kernel a scrivere uno script che li aiutasse 165in questa ricerca: 166 167:: 168 169 .../scripts/get_maintainer.pl 170 171Se questo script viene eseguito con l'opzione "-f" ritorner�� il manutentore(i) 172attuale per un dato file o cartella. Se viene passata una patch sulla linea di 173comando, lo script elencher�� i manutentori che dovrebbero riceverne una copia. 174Questo �� la maniera raccomandata (non quella con "-f") per ottenere la lista di 175persone da aggiungere a Cc per le vostre patch. Ci sono svariate opzioni che 176regolano quanto a fondo get_maintainer.pl debba cercare i manutentori; siate 177quindi prudenti nell'utilizzare le opzioni pi�� aggressive poich�� potreste finire 178per includere sviluppatori che non hanno un vero interesse per il codice che 179state modificando. 180 181Se tutto ci�� dovesse fallire, parlare con Andrew Morton potrebbe essere 182un modo efficace per capire chi �� il manutentore di un dato pezzo di codice. 183 184Quando pubblicare 185----------------- 186 187Se potete, pubblicate i vostri intenti durante le fasi preliminari, sar�� 188molto utile. Descrivete il problema da risolvere e ogni piano che �� stato 189elaborato per l'implementazione. Ogni informazione fornita pu�� aiutare 190la comunit�� di sviluppo a fornire spunti utili per il progetto. 191 192Un evento che potrebbe risultare scoraggiate e che potrebbe accadere in 193questa fase non �� il ricevere una risposta ostile, ma, invece, ottenere 194una misera o inesistente reazione. La triste verit�� �� che: (1) gli 195sviluppatori del kernel tendono ad essere occupati, (2) ci sono tante persone 196con grandi progetti e poco codice (o anche solo la prospettiva di 197avere un codice) a cui riferirsi e (3) nessuno �� obbligato a revisionare 198o a fare osservazioni in merito ad idee pubblicate da altri. Oltre a 199questo, progetti di alto livello spesso nascondono problematiche che si 200rivelano solo quando qualcuno cerca di implementarle; per questa ragione 201gli sviluppatori kernel preferirebbero vedere il codice. 202 203Quindi, se una richiesta pubblica di commenti riscuote poco successo, non 204pensate che ci�� significhi che non ci sia interesse nel progetto. 205Sfortunatamente, non potete nemmeno assumere che non ci siano problemi con 206la vostra idea. La cosa migliore da fare in questa situazione �� quella di 207andare avanti e tenere la comunit�� informata mentre procedete. 208 209Ottenere riscontri ufficiali 210---------------------------- 211 212Se il vostro lavoro �� stato svolto in un ambiente aziendale - come molto 213del lavoro fatto su Linux - dovete, ovviamente, avere il permesso dei 214dirigenti prima che possiate pubblicare i progetti, o il codice aziendale, 215su una lista di discussione pubblica. La pubblicazione di codice che non 216�� stato rilascio espressamente con licenza GPL-compatibile pu�� rivelarsi 217problematico; prima la dirigenza, e il personale legale, trover�� una decisione 218sulla pubblicazione di un progetto, meglio sar�� per tutte le persone coinvolte. 219 220A questo punto, alcuni lettori potrebbero pensare che il loro lavoro sul 221kernel �� preposto a supportare un prodotto che non �� ancora ufficialmente 222riconosciuto. Rivelare le intenzioni dei propri datori di lavori in una 223lista di discussione pubblica potrebbe non essere una soluzione valida. 224In questi casi, vale la pena considerare se la segretezza sia necessaria 225o meno; spesso non c'�� una reale necessit�� di mantenere chiusi i progetti di 226sviluppo. 227 228Detto ci��, ci sono anche casi dove l'azienda legittimamente non pu�� rivelare 229le proprie intenzioni in anticipo durante il processo di sviluppo. Le aziende 230che hanno sviluppatori kernel esperti possono scegliere di procedere a 231carte coperte partendo dall'assunto che saranno in grado di evitare, o gestire, 232in futuro, eventuali problemi d'integrazione. Per le aziende senza questo tipo 233di esperti, la migliore opzione �� spesso quella di assumere uno sviluppatore 234esterno che revisioni i progetti con un accordo di segretezza. 235La Linux Foundation applica un programma di NDA creato appositamente per 236aiutare le aziende in questa particolare situazione; potrete trovare pi�� 237informazioni sul sito: 238 239 http://www.linuxfoundation.org/en/NDA_program 240 241Questa tipologia di revisione �� spesso sufficiente per evitare gravi problemi 242senza che sia richiesta l'esposizione pubblica del progetto. 243