В дальнейшем подобное продление поставлено под сомнение, так как отмечается снижение интереса к использованию старых LTS-ядер — большинство пользователей заранее переводят свои продукты на более новые ветки ядра и 6 лет воспринимается как избыточный срок. Кроме того, по мере увеличения числа LTS-ядер увеличивается нагрузка на сопровождающих, работа которых превращается в рутину и сводится к непрерывному бэкпортированию исправлений. Подобная нагрузка приводит к выгоранию сопровождающих и потере интереса к продолжению работы.
Выгорание сопровождающих оценивается как одна из наиболее серьёзных проблем в сообществе разработчиков ядра. Несмотря на поддержку корпораций большинство участников разработки ядра действуют ради интереса в качестве добровольцев — за свою работу оплату получает лишь около 200 разработчиков из более 2000 активных участников разработки. Постоянное монотонное исправление мелких ошибок, fuzzing-тестирование и рецензирование изменений изматывает разработчиков и приводит к потере интереса к продолжению выполнения работы сопровождающего.
Из проблем также отмечается опасность возникновения веток ядра Linux, расходящихся с основным ядром и зависящих от отдельных поставщиков. Подобные ветки могут стать результатом использования в дистрибутивах, таких как Red Hat Enterprise Linux, пакетов с ядром, основанных на очень старых версиях ядра с бэкпортированными изменениями. Опасность подобных веток в том, что в них могут быть не перенесены исправлениях уязвимостей и серьёзных проблем, а также затруднён разбор возникающих ошибок (непонятно, проявляется ли проблема в основном ядре или вызвана специфичными изменениями производителя).
В качестве более правильной упоминается модель сопровождения ядер для платформы Android, основанная на переносе всех изменении из основного ядра и развитию необходимых новшеств в основном ядре, вместо поддержания собственного варианта ядра, включающего изменения, специфичные для платформы Android. Модель полного переноса изменений выгодна прежде всего с точки зрения безопасности, так как, при выборочном переносе исправлений не всегда очевидна связь исправления с устранением потенциальных проблем с безопасностью. При полном переносе изменений проблема часто оказывается решена ещё до того, как появляется информация о том, что она блокирует уязвимость.
Источник: http://www.opennet.ru/opennews/art.shtml?num=59791