Linus sfida Paragon e critica GitHub per le fusioni

Linus Torvalds è noto per è molto esigente riguardo alle procedure e agli standard che coloro che aiutano a sviluppare il kernel Linux devono seguire. E di solito non è molto gentile con coloro che non sono all'altezza del compito. Ricordiamo che in passato si è ritirato per un po' dal suo ruolo per ripensare al modo in cui si relazionava con le altre persone.

Questa volta, è stata Paragon Software, la società dietro il driver NTFS3, a incorrere nella sua antipatia.  Annunciato per la versione 5.15 del kernel Linux, migliorerà il supporto per il file system nativo di Windows.

Sistemi di controllo versione (MCS)

Per capire questa storia, spiegheremo alcuni dettagli che non tutti devono conoscere.

Gli sviluppatori di progetti software molto complessi utilizzano software di controllo della versione (generalmente gestito da un provider esterno nel cloud) Questo software ti consente di tenere traccia di chi, quando e cosa apporta modifiche.

Se non fai parte dei membri del progetto, puoi fare un fork, cioè copiare i file del progetto nel tuo repository e, in esso, apportare le tue modifiche. Se ti piace il risultato puoi suggerire all'amministratore del progetto originale di incorporarli, chiamando richiesta pull.

Rilascio del controller

L'anno scorso, Paragon Software aHa annunciato il rilascio del codice del controller, da lui precedentemente commercializzato, impegnandosi anche a curarne la manutenzione e l'aggiornamenton. Questa è una buona notizia in quanto è molto migliore di quella che stavamo utilizzando attualmente.

Secondo l'azienda stessa

La versione attuale funziona con file normali / compressi / spaziosi e supporta acl, la riproduzione del journal NTFS. La maggior parte del codice era nel ramo linux-next dal 13 agosto, ma ci sono alcune patch, che erano nel ramo linux-next solo per un paio di giorni. Si spera che sia tutto a posto: nei test non è stata rilevata alcuna regressione.

Dopo l'annuncio di Paragon, il Il driver NTFS3 ha dovuto passare attraverso molti cicli di revisione per migliorare la qualità del codice e renderlo conforme agli standard di codifica del resto del kernel.

Sembra che alla fine ce l'abbia fatta.

E così arriviamo alla madre delle pecore.

Linus sottrae Paragon

Per includere il driver nella versione del kernel 5.15, Linus Torvalds ha chiesto a Paragon Software di farlo richiesta di pull di cui abbiamo parlato sopra. La società lo ha fatto, ma non nel modo in cui piace a Torvalds.

La prima osservazione del finlandese è stata che la richiesta pull avrebbe dovuto essere firmata.

In un mondo perfetto, questa sarebbe una firma PGP che potrebbe risalire direttamente a te attraverso la catena di fiducia, ma non l'ho mai richiesta.

In secondo luogo, si è lamentato del fatto che la richiesta pull era stato fatto dall'interfaccia web del servizio, che produce molto codice spazzatura.

Github è un ottimo sito di hosting e fa bene anche una serie di altre cose, ma le fusioni non sono una di queste cose.

Ha anche protestato mancanza di informazioni sufficienti.

Per il creatore di Linux "Le unioni del kernel Linux devono essere eseguite correttamente". E aggiunse: «Ciò significa messaggi di commit appropriati con informazioni su cosa viene unito e * perché * qualcosa viene unito. Ma significa anche informazioni corrette su paternità e committente, ecc. Tutto ciò che GitHub ha completamente incasinato.

Linus Torvalds sa di cosa sta parlando, è stato il creatore di Git, il software su cui si basano servizi come GitHub, ora di proprietà di Microsoft. E, curiosamente, era dovuto al disaccordo con un altro servizio

Non ho mai voluto creare un programma di controllo della versione perché li odiavo tutti… Poi è arrivato BitKeeper e ha davvero cambiato il modo in cui li guardo. BK ha fatto la maggior parte delle cose nel modo giusto e avere una copia locale del repository e un merge distribuito era molto importante. La cosa grandiosa del controllo distribuito dell'origine è che fa sparire uno dei problemi principali con gli MCS: la politica intorno a "chi può apportare modifiche".

BK ha mostrato che questo può essere evitato dando a tutti il ​​proprio repository. Ma anche BK aveva i suoi problemi; ci sono state alcune decisioni tecniche che hanno causato problemi (il rinominare è stato doloroso), ma il più grande svantaggio è stato il fatto che, poiché non era open source, c'erano molte persone che non volevano usarlo. Quindi, anche se abbiamo finito per avere diversi manutentori del kernel che usano BK - era gratuito per i progetti open source - non è mai diventato enorme, quindi ha aiutato lo sviluppo del kernel, ma non è stato perfetto.

Quindi ad un certo punto ho deciso che non potevo continuare a usare BK, ma non volevo davvero tornare ai vecchi tempi pre-BK. Purtroppo, all'epoca, mentre c'erano alcuni altri SCV che più o meno hanno cercato di distribuire la cosa, nessuno di loro ha funzionato bene. Avevo requisiti di prestazioni che non erano nemmeno lontanamente soddisfatti da ciò che era disponibile, e mi preoccupavo anche dell'integrità del codice e dell'intero flusso di lavoro, quindi ho deciso di scriverne uno mio.