Che s'ha da fare per contribuire

Lun, 05/10/2015 - 00:25
Ritratto di mcortese

Che s'ha da fare per contribuire

Inviato da mcortese 0 commenti

Di solito le discussioni sulla Linux Kernel Mailing List sono talmente tecniche da risultare noiose, ma qualche volta i toni si scaldano quando questo o quello sviluppatore cerca di difendere a spada tratta la soluzione che sta propugnando e in quel caso non si risparmiano attacchi personali al limite dell'insulto. La discussione che ha animato la mailing list a settembre è atipica, non tanto nei toni surriscaldati, quanto nel quesito ben poco tecnico che ne è alla base, cioè se sia giusto o no incoraggiare i novellini a scrivere e proporre correzioni banali, al limite anche meri ritocchi estetici.

La discussione (che può essere seguita su gmane) comincia quando lo sconosciuto Eric Curtin invia la sua prima patch con un messaggio intitolato, appunto, "First kernel patch (optimization)". La mail è discutibile sotto molti punti di vista: la descrizione è scritta male e intitolata anche peggio e l'impaginazione, lasciata al mail agent, non è in linea con gli standard del kernel. Inoltre la patch ha l'intento di ottimizzare una porzione di codice assolutamente non critica e quindi è immediatamente classificata come eccesso di zelo da più d'un veterano della lista.

Eric, probabilmente deluso dallo scarso entusiasmo con cui il suo contributo è stato accolto, manda alla lista una richiesta di chiarimenti in questi termini:

Citazione:

Sono un novellino del kernel. Ho scelto qualcosa super semplice tanto per capire quale fosse il processo per farsi approvare una patch. Viste le vostre risposte, devo astenermi dal mandare altre di queste micro-ottimizzazioni in futuro?

La risposta di Ted Ts'o è brutale: gli dice che le micro-ottimizzazioni come la sua non fanno il bene della comunità e arriva a insinuare che a motivare Eric sia solo la voglia di "collezionare uno scalpo (yuhu! una mia patch è finita dentro il kernel)", magari per farsi bello al prossimo colloquio. Nei messaggi successivi aggiunge che ogni modifica del kernel ha un costo di gestione e le energie investite in patch di utilità marginale sono distratte dai casi che davvero richiedono l'attenzione degli sviluppatori.

Di opposto parere è Greg Kroah-Hartman, per il quale interventi banali come quello di Eric non sono che il primo passo, inutile ma necessario, per diventare ferrati nella delicata arte di contribuire al kernel Linux. Saper scrivere una patch non basta: occorre anche metterla in una forma accettabile, corredarla di descrizione e tag opportuni, confezionarla in una mail con determinate proprietà e infine inviarla al destinatario giusto. Tutto questo si impara soltanto provando con un caso semplice.

Dopo un feroce scambio di battute tra i due veterani del kernel, la discussione si esaurisce come al solito: ciascuno rimane del proprio avviso. Ted Ts'o continuerà a rifiutarsi di esaminare le micro-ottimizzazioni proposte dei novellini per dedicarsi invece a cose più urgenti, mentre Greg KH continuerà ad accogliere (nel ramo drivers/staging da lui gestito) le reclute che vorranno intraprendere questo difficile cammino. Eric ripropone la sua patch, ora con il formato corretto, che finalmente riceve l'attenzione che merita, ma non sembra comunque destinata a entrare nel kernel.

L'epilogo inaspettato arriva diversi giorni dopo, quando Linus in persona interviene a sostegno della patch di Eric, adducendo due motivi. Il primo è che il codice ottimizzato da Eric è migliore di quello esistente. Non importa se la sezione non è critica o se il vantaggio è marginale: promuovere il miglior codice possibile è un validissimo obiettivo in sé. Il secondo motivo è che, rispetto ad altre patch d'esordio, quella di Eric è ben ragionata, non è la classica modifica scaturita da un warning del compilatore o da qualche check automatico della formattazione. Linus riconosce quindi che il suo autore potrebbe avere quel potenziale che la comunità del kernel dovrebbe incoraggiare.

Non sappiamo se alla fine la patch sarà applicata o meno, ma, in ogni caso, Eric avrà imparato molto su come collaborare allo sviluppo del kernel e forse un giorno arriverà a contribuire in modo significativo a migliorare la nostra esperienza di utenti Linux.