Nach Hector Martins Rücktritt als Maintainer und Beendung seiner Mitarbeit an der Überprüfung von Paketen gab auch Karol Herbst (Karol Herbst) bekannt, dass er seine Aufgaben als Maintainer niederlegt. Er war für den Nouveau-Treiber und den MMIOTRACE-Mechanismus verantwortlich und arbeitete bei Red Hat. Nach seinem Rücktritt werden noch zwei Maintainer im Kern verbleiben, die den Nouveau-Treiber unterstützen und laut Karol ihre Arbeit hervorragend erledigen.
Als Grund für seinen Rücktritt wird das Fehlen von Atmosphäre der Inklusivität unter den Kernel-Entwicklern genannt. Karol ist überzeugt, dass in der Open-Source-Entwicklung Respekt, Gleichheit und der Verzicht auf Machthierarchien herrschen sollten. Laut Karol war das letzte Nadelöhr eine Nachricht von Theodore Ts'o, in der er die Maintainer mit einer "dünnen blauen Linie" verglich, die mit den Strafverfolgungsbehörden assoziiert wird und die Grenze zwischen Ordnung und Anarchie symbolisiert und darauf besteht, dass der in den Kernel aufgenommene Code unterstützbar und qualitativ hochwertig ist.
Laut Karol kann jemand, der solche Worte äußert, nicht die Rolle eines Begleiters einnehmen, egal wie wichtig er für das Projekt ist, und sollte ausgeschlossen werden, bevor er realisiert, was diese Worte für viele marginalisierte Menschen bedeuten und welche Schrecken sie in ihren Köpfen auslösen. Karol zieht sich zurück, da er nicht in einer Gemeinschaft bleiben kann, die solche Worte toleriert.
Theodor Ts'o zog einen Vergleich mit der dünnen blauen Linie während der Diskussion über den Widerstand älterer Entwickler gegen die Integration von Rust in den Kernel. Er schrieb, dass die Macht der Maintainer begrenzt ist und sie keinen Einfluss auf die Fortführung der Entwicklung bereits akzeptierter Änderungen haben, da sie nicht anordnen können, dass Leute an Verbesserungen und der Testinfrastruktur arbeiten. Das einzige Mittel zur Qualitätssicherung ist die Fähigkeit der Maintainer, die Aufnahme von rohen und fragwürdigen Änderungen in den Kernel zu verhindern. Sobald der Code akzeptiert ist, verlieren die Maintainer ihre Hebelwirkung auf die Entwickler und werden persönlich haftbar für diesen Code.
Bei einer erheblichen Änderung müssen die Verantwortlichen sicherstellen, dass die Änderung vollständig funktioniert und die Entwickler in der Lage sind, den Code nach dem Einpflegen in den Kern zu unterstützen, ohne ihn unbeaufsichtigt zu lassen. Theodor nennt als Beispiel Teams, die nur an der Promotion ihres Projekts interessiert sind und sobald der Code akzeptiert wird, verschwinden und nicht mehr auftauchen, während die Maintainer alle aufgetretenen Mängel beheben müssen.
Von einigen gibt es Anschuldigungen wegen doppelter Standards, da der Code einiger Entwickler nahezu sofort akzeptiert wird, während der Code anderer lange bearbeitet wird. In dieser Angelegenheit sind das etablierte Vertrauen und der verdiente Ruf wichtig. Wenn ein Entwickler bereits seine Fähigkeit unter Beweis gestellt hat, für die eingereichten Änderungen verantwortlich zu sein, gehen die Genehmigungen schnell durch. Bei Neuankömmlingen kann die Annahme von Änderungen länger dauern, da der Begleiter verstehen muss, ob der Teilnehmer für seinen Code verantwortlich sein kann. Daher müssen die Teilnehmer, insbesondere diejenigen, die versuchen, radikale Änderungen voranzutreiben, viel Zeit investieren, um Teil der Gemeinschaft zu werden. Zum Beispiel hat die Integration von Änderungen für den Kernel-Build mit dem Clang-Compiler zehn Jahre gedauert.
Quelle: opennet.ru
