Chiusura della finestra di unione di Linux 6.17 ha lasciato un episodio frenetico: un pacchetto di modifiche per RISC-V è stato rifiutato da Linus Torvalds perché includeva modifiche inappropriate alle intestazioni generiche ed era stato inoltre inviato fuori tempo.
La spedizione, effettuata da Palmer Dabbelt (team Android di Google), ha raggiunto praticamente il limite e ha toccato aree comuni del kernel con quella che Torvalds ha definito "spazzatura", il che ha motivato un veto immediato e la richiesta di riprovare nella successiva finestra di integrazione. Ulteriori informazioni sugli avvertimenti di Torvalds agli utenti
Quello che è successo
Il lotto di modifiche è stato inviato poco prima del rilascio del prima release candidate di Linux 6.17, un momento in cui le nuove integrazioni di funzionalità non rientra più nella pianificazione del progettoPer comprendere meglio gli aggiornamenti di Linux 6.17, puoi rivedere Le principali novità di Linux 6.16.
Torvalds ha individuato due problemi principali: da un lato, l'arrivo tardivo della richiesta di pull, in contrasto con le linee guida comunicate ai manutentori; e, d'altro canto, l'inclusione di modifiche agli header condivisi che non erano strettamente necessarie per RISC-V. Vuoi seguire le politiche di integrazione del progetto? Revisione Le dichiarazioni di Torvalds sulla disciplina del kernel.
Uno dei punti più notevoli è stata l'introduzione di un assistente macro, make_u32_from_two_u16(), che a parere del responsabile del progetto ridotta leggibilità del codice y aggiunta ambiguità riguardo all'ordine degli argomentiPer un approfondimento sui miglioramenti apportati alla versione, visita Tutto su Linux 6.17 e le sue patch.
Nella cultura del kernel, Le modifiche specifiche di un'architettura devono rimanere all'interno dell'albero di quell'architettura salvo casi giustificati e concordati; toccare le intestazioni comuni comporta effetti collaterali per l'intero ecosistema.
Chi era coinvolto e perché era fastidioso
La spedizione è stata firmata da lui Palmer Dabbelt, ingegnere del team Android, con modifiche mirate a RISC-V ma che estendono il loro ambito agli header trasversali del kernel, che hanno attivato allarmi di revisione. Per comprendere come ciò influisca su progetti specifici, vedere miglioramenti in Linux 6.16.
Giorni prima, Torvalds aveva richiesto richieste di fusione anticipate Per motivi di programmazione, la scadenza è stata interpretata come una violazione delle regole del processo. Per maggiori dettagli, vedere cosa c'è di nuovo in Linux 6.13.
Il messaggio era chiaro: Non ci saranno più richieste di pull tardive. né modifiche che sporcassero inutilmente le aree comuni. L'invito è stato lasciato sul tavolo per riprovare in 6.18, entro la finestra temporale appropriata e con un ambito più limitato.
Reazioni e contesto
D'altro canto, Dabbelt rispose con tono conciliante, impegnandosi a rispettare le tempistiche e a limitare le modifiche alle aree RISC-V in modo da non influire sulle intestazioni condivise. Per comprendere meglio l'importanza del controllo di qualità , vedere miglioramenti in Linux 6.10.
L'episodio ha riacceso il dibattito su come bilanciare l'apertura dello sviluppo con disciplina tecnicaSu Linux, L'inclusività non significa accettare alcun cambiamento: richieste coerenza, chiarezza e qualità Per saperne di più sulla disciplina nei progetti Open Source, visita Sistemi ARM e Linux.
La reazione è in linea con le recenti decisioni di Torvalds di proteggere la stabilità dell'albero, ricordando che le regole di schedulazione e integrazione non sono decorative, ma piuttosto strumenti per evitare regressioni e debito tecnico. Per comprendere l'importanza della schedulazione nello sviluppo, leggi cosa c'è di nuovo in Linux 5.19.
Guardando al breve termine, Linux 6.17 continuerà senza queste patch, mentre il lavoro per RISC-V potrebbe essere riproposto nella versione 6.18 se rispetta le linee guida e le modifiche estetiche che ne ostacolano la lettura vengono accantonate.
La combinazione di una consegna ravvicinata, Modifiche alle intestazioni generiche e un helper controverso È servito da promemoria: nel kernel, le modifiche devono essere tempestive, necessarie e migliorare la chiarezza, non il contrario.