Come molti di voi sapranno, alcuni anni fa Greg Kroah-Hartman, che dopo Linus Torvalds è forse la persona più vicina al Kernel (un po’ come Virgo era il cavaliere più vicino ad Atena dopo Arles), aveva annunciato l’estensione del mantenimento a sei anni per quelle versioni stable del Kernel rientranti nella categoria LTS (Long Term/Time Support).
Da allora di codice sotto i ponti ne è passato parecchio, basti pensare che l’annuncio era stato fatto per la versione 4.4 del Kernel Linux ed oggi siamo alla 5.10 (per quanto il passaggio di major release nel Kernel Linux sia piuttosto arbitrario, di fatto in base all’umore di Torvalds).
Ebbene, la questione LTS è ritornata recentemente alle cronache per via di un post pubblicato da Kroah-Hartman dal titolo piuttosto eloquente: Helping Out With LTS Kernel Releases.
Facendo riferimento a un recente thread apparso sulla mailing list del Kernel nel quale si chiedeva come mai la versione 5.10 del kernel non veniva indicata come supportata per sei anni, il maintainer del Kernel Linux ha spiegato che sostanzialmente per mantenere il codice per più di due anni ha… Bisogno di aiuto.
Con la consueta precisione ha anche indicato la modalità in cui è possibile supportare, e cioè effettuando dei test sulle versioni -rc dei Kernel uscenti. Quindi a fronte della pubblicazione delle patch nominate in base alla release, tipicamente in un thread dal titolo simile a [PATCH 5.10 00/32] 5.10.12-rc1 review nella mailing list del Kernel, basterà indicare l’esito dei propri test in questo modo:
Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 427 pass: 427 fail: 0
Tested-by: <TUO NOME> <tua@mail>Chiaramente questa forma pubblica è certamente la più gradita, ma non essendo accessibile a tutti, le cose possono anche essere gestite dopo che le release sono uscite:
Some companies can’t do tests on -rc releases due to their build infrastructures not handling that very well, so they email me after the stable release is out, saying all is good. Worst case, we end up reverting a patch in a released kernel, but it’s better to quickly do that based on testing than to miss it entirely because no one is testing at all.
Alcune aziende non possono fare test sui rilasci -rc a causa delle loro infrastrutture di compilazione che non lo gestiscono molto bene, così mi mandano un’email dopo che il rilascio stabile è uscito, dicendo che tutto è a posto. Nel peggiore dei casi, finiamo per ripristinare una patch in un kernel rilasciato, ma è meglio farlo rapidamente sulla base dei test piuttosto che perderlo completamente perché nessuno lo sta testando.
Ed inoltre Kroah-Hartman invita anche gli utenti ad indicare i backport da includere nelle release dopo aver effettuato i vari test, scrivendo alla lista stable@vger.kernel.org o a lui personalmente (!).
Tutto questo oltre a far riflettere sul grado di complessità che il ruolo di Kernel Maintainer richiede, mette anche in luce l’evidente peso che figure come quelle di Torvalds e Kroah-Hartman hanno in merito alla sopravvivenza del Kernel Linux, non solo per le versioni LTS.
Ma quindi in conclusione il Kernel 5.10 sarà LTS o no? Nella sostanza dipenderà dai contributi ricevuti, in particolare da quelle aziende che hanno richiesto la cosa che a detta del Maintainer ancora non si sono fatte vive 🙂
Bisognerà seguire la pagina https://www.kernel.org/category/releases.html e capire se per la versione 5.10 la Projected EOL rimarrà Dec, 2022 (quindi 2 anni), oppure verrà estesa.
In conclusione, è bene ricordare che molte cose date per scontate, come il fatto che una release del Kernel Linux, che ricordiamo essere un progetto totalmente open-source, venga supportata per 6 anni, ebbene, forse non lo sono così tanto.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Lascia un commento