След Заминаването на Хектор Мартин като Поддържащ платформата на ARM/Apple В основния клон на ядрото се отвори нова глава в поддръжката на ядрото, както сега, Карол Хербст, който изигра ключова роля (той отговаряше за контролера Nouveau и инструмента за проследяване MMIO), също е решил да се оттегли от задълженията си като поддържащ и спрете да участвате в преглед на корекции.
Коментирайки решението си, Карол Хербст подчерта, че въпреки неговото напускане, двама поддържащи ще продължат да поддържат контролера, вършейки това, което той смята за „страхотна работа“.
Решението от Карол се основава на тяхното недоволство от липсата на приобщаваща среда в рамките на основната група разработчици, където, според неговата визия, сътрудничеството трябва да се основава на взаимно уважение и справедливост, без да се позволява на определени мълчаливи правомощия да влияят на процеса.
Споровете се засилиха зад Публикацията на Теодор Цокойто Той използва метафората за „тънка синя линия“”, за да опише ролята на поддържащите, сравнявайки ги с бариера, която разделя реда от анархията и гарантира качеството и устойчивостта на приетия код.
Ще ви кажа една тайна: хората по поддръжката не са „всемогъщи“.
Те са „тънката синя линия“, която се опитва да поддържа кода неподвижен, mиздръжлив и висококачествен. Като повечето лидери на доброволци в организация, независимо дали е работната група на интернет инженерите (the орган за интернет стандарти), всъщност имаме много малко власт.
Не можем да *наредим* на хората да работят за анулиране на технически дълг или за mподобряване на инфраструктурата за тестване или работа по конкретна функция което наистина бихме искали за нашите потребители.Всичко, което можем да направим, е да предотвратим приемането на нещата (независимо дали в нашия
подсистема или IETF imprimatur). Дано да сме само
Спрете лошите неща да напредват, но това е *наистина* всичко, което можем да направим.
За Карол използването на такава аналогия е неприемливо, Той пренебрегва отрицателното въздействие, което може да има върху маргинализирани хора и върху възприемането на общност, която трябва да бъде приобщаваща.
Дебатът също така подчертава, че поддържащи, макар и от съществено значение за да избегнете включването на нестабилни или недостатъчни промени, Те губят част от влиянието си, след като кодът е интегриран в ядрото, като носи отговорност за всички последващи последствия. Този сценарий се влошава, когато екипи, които се интересуват само от популяризиране на собствените си творения, изчезват след приемането на кода, оставяйки поддържащите с трудната задача да коригират грешките.
Едно от нещата, които са много разочароващи от страна на поддържащия
Перспективата са екипите за разработка, които се интересуват само от своя любимец характеристика и *знаем* от много горчив опит, че повече от 95% отС течение на времето, след като кодът бъде приет...Кодът ще изчезне и никога повече няма да бъде видян. В резултат на а общата динамика е, че поддържащите ще упражняват единствено и изключително властта, която имат - която е да отказват да приемат кода, докато На практика е идеално — тъй като щом приемем кода, ние незабавно Ще загубим всички лостове и данъкоплатците ще изчезнат, а ние ще... бъдете оставени с отговорността да почистите бъркотията.
Положението Той също така разкри очевиден двоен стандарт в процеса на интегриране на промените: Докато работата на „любимите“ разработчици се одобрява почти незабавно, предложенията от нови членове са изправени пред много по-строг преглед, за да се демонстрира тяхната надеждност, въпреки че в последния случай можем да разберем защо, тъй като много практичен пример за това е случаят с помощната програма „XZ“.
От другата страна на монетата е случаят с компилатора Clang, чиито промени отнеха десетилетие, за да се консолидират в процеса на изграждане на ядрото, което подчертава необходимостта от време и доверие за безопасно интегриране на радикални иновации.
Без съмнение всичко това, което се появява в рамките на екипа за разработка на Linux, ще се превърне в една от основите, които ще спомогнат за насърчаването на среда, в която разнообразието и уважението са основни стълбове на сътрудничеството в отворен код.