Subito dopo Hector Martin, anche Karol Herbst ha annunciato il suo disimpegno dalle funzioni di maintainer e la cessazione della sua partecipazione nella revisione delle patch. Karol Herbst, che ha seguito il driver Nouveau e il meccanismo di tracciamento MMIO (MMIOTRACE), lavora per Red Hat. Dopo la sua partenza, rimarranno nel kernel ancora due maintainer che supportano il driver Nouveau, i quali, secondo Karol, fanno un ottimo lavoro.
Come motivo della sua partenza, viene menzionata l'assenza di un'atmosfera di inclusività tra gli sviluppatori del kernel. Karol è convinto che, nella comunità del software open-source, il lavoro debba essere svolto con rispetto, su un piano di parità e senza abusare del potere. Secondo Karol, l'ultima goccia è stata il messaggio di Theodore Ts’o, nel quale ha paragonato i maintainer a una "sottile linea blu" (associata alle forze dell'ordine e simbolo del confine tra ordine e anarchia), che si impegna affinché il codice integrato nel kernel sia sostenibile e di qualità.
Secondo Karol, chi esprime tali parole non può ricoprire il ruolo di maintainer, indipendentemente da quanto sia importante per il progetto, e deve essere escluso prima che comprenda cosa significano davvero per molte persone emarginate e quali orrori suscitano nelle loro menti. Karol lascia perché non può rimanere in una comunità che può tollerare tali parole.
Theodore Ts’o ha fatto un confronto con la sottile linea blu durante la discussione sulla resistenza degli sviluppatori più anziani alla promozione di Rust nel kernel. 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 su miglioramenti e sull'infrastruttura di test. L'unico strumento per garantire la qualità è la capacità dei maintainer di impedire l'inclusione nel kernel di modifiche grezze e discutibili. Una volta che il codice è stato accettato, i maintainer perdono la loro leva sui programmatori e diventano personalmente responsabili di quel codice.
Accettando un cambiamento significativo, i manutentori devono essere certi che la modifica funzioni completamente, e che i suoi sviluppatori siano in grado di mantenere il codice dopo l'inserimento nel core e non lascino il codice senza supervisione. Teodoro cita come esempio i team interessati solo a promuovere la loro creazione, che, una volta che il codice è stato accettato, scompaiono e non riappaiono più, mentre i manutentori devono affrontare tutti i problemi irrisolti.
Alcuni avanzano accuse di doppi standard, poiché il codice di alcuni sviluppatori viene accettato quasi immediatamente, mentre il codice di altri viene lavorato a lungo. In questa questione, la fiducia stabilita e la reputazione meritata sono fondamentali. Se uno sviluppatore ha già dimostrato la sua capacità di rispondere per le modifiche apportate, le approvazioni avvengono rapidamente. Per i nuovi arrivati, l'accettazione delle modifiche può richiedere più tempo, poiché il mantenitore deve capire se il partecipante sarà in grado di rispondere per il proprio codice. Pertanto, i partecipanti, soprattutto quelli che cercano di promuovere modifiche radicali, devono spendere molto tempo per diventare parte della comunità. Ad esempio, per integrare le modifiche per la compilazione del kernel con il compilatore Clang ci sono voluti 10 anni.
Fonte: opennet.ru
