]>
Commit | Line | Data |
---|---|---|
edba5eec FV |
1 | .. include:: ../disclaimer-ita.rst |
2 | ||
3 | :Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>` | |
fdf0345e | 4 | :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it> |
edba5eec FV |
5 | |
6 | .. _it_development_early_stage: | |
7 | ||
fdf0345e FV |
8 | I primi passi della pianificazione |
9 | ================================== | |
edba5eec | 10 | |
fdf0345e FV |
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. | |
edba5eec | 17 | |
fdf0345e FV |
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. |