Ужесточение правил заморозки кода ядра
Существующие уже давно правила заморозки кода при разработке ядра Linux разрешают выполнять вливание существенных изменений в основную ветку только до выхода первого релиз-кандидата новой версии (RC1), после чего в основную ветку должны приниматься только исправления серьезных ошибок. Однако на практике эти правила зачастую игнорировались, и даже после выхода RC1 и RC2 в ядро принимались не только исправления ошибок, но и улучшения функционала. Такой подход практиковался вплоть до недавнего времени, в частности, именно так готовился 2.6.35-rc2. Однако непосредственно перед выходом второго релиз-кандидата 2.6.35 Торвальдс неожиданно начал жестко отказывать в просьбах ввести в основную ветку ядра не связанные с исправлением ошибок изменения.
Одной из причин, побудившей лидера разработки ядра Linux вернуться к жесткому соблюдению правил заморозки, стал недавний внешне вполне безобидный коммит, который привел к появлению возможности случайной перезаписи различных областей памяти ядра, что, в свою очередь, повлекло за собой большое количество плохо диагностируемых ошибок. Стоит отметить, что это коммит являлся попыткой исправления ошибки, впрочем, довольно незначительной. Другой причиной стало желание Торвальдса уйти в небольшой отпуск после выхода RC3, оставив тестерам код более-менее приемлемого качества.
