LiveStreet

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

Одной из причин, побудившей лидера разработки ядра Linux вернуться к жесткому соблюдению правил заморозки, стал недавний внешне вполне безобидный коммит, который привел к появлению возможности случайной перезаписи различных областей памяти ядра, что, в свою очередь, повлекло за собой большое количество плохо диагностируемых ошибок. Стоит отметить, что это коммит являлся попыткой исправления ошибки, впрочем, довольно незначительной. Другой причиной стало желание Торвальдса уйти в небольшой отпуск после выхода RC3, оставив тестерам код более-менее приемлемого качества.

Взято с opennet.ru.

От себя: Давно пора было. Никогда не понимал, почему разработчикам не хватает двух недель для внесения всех необходимых изменений при том, что основные из них готовы уже перед выпуском предыдущей версии. Хочется надеяться, что принятием таких жёстких мер удастся немного уменьшить время подготовки очередной версии (сейчас в среднем 3 месяца), а также увеличить качество результирующего кода.