Dopo Héctor Martín, anche Karol Herbst ha annunciato il suo ritiro come maintainer e la cessazione della partecipazione alla revisione dei pacchetti. Karol, che ha sostenuto il driver Nouveau e il meccanismo di tracciamento MMIO (MMIOTRACE) presso Red Hat, ha dichiarato che nel kernel rimarranno ancora due maintainer del driver Nouveau, che a suo avviso stanno svolgendo un ottimo lavoro.
Come motivo del ritiro si fa riferimento all'assenza di un'atmosfera di inclusività tra gli sviluppatori del kernel. Karol è convinto che nella comunità del software open source si debba lavorare con rispetto, all'uguaglianza e senza giochi di potere. Secondo Karol, l'ultima goccia è stata un messaggio di Theodore Ts'o, in cui ha paragonato i maintainer a una "fine linea blu" (associata alle forze dell'ordine e simbolo del confine tra ordine e anarchia), che si sforza affinché il codice accettato nel kernel sia mantenuto e di qualità.
Secondo Carol, chi pronuncia tali parole non può rivestire un ruolo di supporto, indipendentemente dall'importanza che ha per il progetto, e dovrebbe essere escluso prima che comprenda cosa queste parole significano per molte persone emarginate e quali orrori suscitano nelle loro menti. Carol se ne va, poiché non può restare in una comunità che tollera tali espressioni.
Theodore Ts'o ha fatto un paragone con una sottile linea blu durante la discussione della resistenza degli sviluppatori più esperti alla promozione di Rust nel nucleo. Ha scritto che il potere dei maintainer è limitato e non possono influenzare il proseguimento dello sviluppo delle modifiche già approvate, poiché non hanno la possibilità di ordinare alle persone di lavorare sulle revisioni e sul miglioramento dell'infrastruttura di test. L'unico strumento per garantire la qualità è la capacità dei maintainer di impedire l'inclusione nel nucleo di modifiche grezze e discutibili. Una volta che il codice è approvato, i maintainer perdono leve di influenza sugli sviluppatori e diventano personalmente responsabili per quel codice.
In caso di modifiche significative, i manutentori devono essere certi che la modifica funzioni completamente e che i suoi sviluppatori siano in grado di mantenere il codice dopo l'accettazione nel nucleo, senza abbandonarlo. Teodor porta come esempio i team interessati solo a promuovere il loro progetto, che scompaiono non appena il codice viene accettato e non ricompaiono più, costringendo i manutentori a gestire tutte le mancanze.
Alcuni ricevono accuse di doppi standard, poiché il codice di alcuni sviluppatori viene accettato quasi immediatamente, mentre quello di altri viene elaborato a lungo. In questo contesto, è fondamentale la fiducia stabilita e la reputazione meritata. Se uno sviluppatore ha già dimostrato di poter rispondere per le modifiche inviate, le approvazioni avvengono rapidamente. Per i novizi, l'accettazione delle modifiche può richiedere più tempo, poiché chi supervisiona deve capire se il partecipante sarà in grado di rispondere per il proprio codice. Pertanto, i partecipanti, soprattutto quelli che cercano di promuovere cambiamenti radicali, devono dedicare molto tempo per diventare parte della comunità. Ad esempio, ci sono voluti 10 anni per integrare le modifiche per la compilazione del kernel con il compilatore Clang.
Fonte: opennet.ru
