Matthew Miller, участник Fedora Cloud SIG и инженер Red Hat, выступил с предложением разделить Fedora на несколько частей - базовая часть, общая для всех, и надстройки, создаваемые в рамках рабочих групп. Базовая часть будет иметь необычное и свежее название - Fedora Core. Его предложение уже с интересом изучается русскоязычными аналитиками на OpenNET.ru

Проблема, которую пытается решить Matthew, заключается в том, что у нас, внутри проекта, есть части, движущиеся с разной скоростью. Например, Firefox и ядро обновляются быстрее всех других, и независимо от версии релиза. Получается, что внутри системы с якобы фиксированным API/ABI, есть части, разрабатываемые по принципу rolling release. Это не единственный пример - разработка приложений Cloud и Virtualization идет настолько быстро, что жесткие требования к API/ABI внутри релиза просто связывает руки мэйнтейнеру, заставляя его тратить много времени на не очень интересную и осмысленную работу по бэкпортированию патчей в старые версии. Опять же пользователи порой хотят и посидеть, и поплясать одновременно - чтоб были стабильные версии всего, кроме вот того и того, которые, как пользователю хочется, должны быть самые распоследние. Мэйнтейнерам постоянно регулярно нарушать политики по недопущению смены API внутри релиза, и Matthew хочет декриминализировать эту практику, выделив проблемные области в особенные сущности. В слайдах он приводит ряд примеров, когда существующая ориентация на пакеты (RPM) мешает, например, установка последней версии приложения из Git.

К сожалению, его небесспорное предложение прямо сейчас полностью несовместимо с существующей инфраструктурой. RPM, являясь, самой продвинутой системой управления пакетами, не имеет развитой инфраструктуры сборки и пересборки, доступной продвинутому пользователю. Не хватает многих нужных функций. Например, сервис для т.н. "chain builds" появился лишь недавно, и, к сожалению, пока непонятно каково его будущее, и какова скорость развития. Получается, что каждый дистрибутив поднимает свои системы для решения этой задачи. Просто сидя, скажем, на 17й Fedora, выбрать пакеты из Rawhide, чтоб они пересобрались для 17, кликая мышкой по чекбоксам не получится - инфраструктуры для этого пока нет. Непонятно, что делать с багзиллой, на какие компоненты открывать тикеты, в случае нахождения ошибок в таких вот пересобранных пакетах? Неясно, как в этой системе будут обеспечиваться повторяемость результатов и идентичность систем, если какие-то компоненты будут плавно изменяться со временем. Что касается сборки пакетов из VCS, то этот таг spec-файла RPM только начинает входить в оборот у мэйнтейнеров, и пока несет лишь информативную нагрузку.

Идеи, конечно, возникли не на пустом месте. Уже обсуждалось разделение EPEL на ряд слоев, обновляющихся с разной скоростью, плюс недавно Red Hat официально представила Software Collections, содержащие актуальные версии современного ПО для разработки. Некоторые аналитики даже поспешили сделать вывод, что Red Hat нужно срочно обкатать новую технологию на тестовых хомячках перед тем, как выпустить ее в продажу, но, разумеется, это беспочвенные домыслы, и низкопробная конспирология.

Так или иначе, это очень хорошо, что были очерчены некоторые негативные моменты, и создан добротный shitstorm тред в мэйллисте. Fedora Project, в отличие от некоторых других дистрибутивов, никогда не сторонилась радикальных перемен, если этого требует историческая необходимость. Например, не так давно мы вновь переосмысливали наше место в жизни, в очередной раз уточняя для кого мы, кроме нас самих, делаем дистрибутив и инфраструктуру? Раньше все было просто - ведущие разработчики OSS и активные квалифицированные (умеющие пользоваться diff и patch, как минимум) пользователи, желающие сотрудничать, это был наш контингент. Нас всегда было немного, порядка 10%, но мы всегда были людьми, которые создают почти весь Open Source, сеть Internet и все сложные индустриальные решения, и это было просто и понятно. Но в последнее время мы заметили ряд существенных изменений:

• Взрывной рост Internet совпал с растущей популярностью Mac OS X среди разработчиков
• GitHub создал для разработчиков социальную сеть, которую все разработчики так долго ждали, повысив связность коммьюнити. Появление GitHub полностью изменило то, как выпускается открытое ПО, одновременно сделав Git де-факто стандартом разработчика, растоптав нескольких конкурентов.
• Появление Cloud и Virtualization технологий в датацентрах. Это радикально изменило то, как можно разворачивать, обновлять, и масштабировать системы.
• 3D-принтеры, ARM, Maker-культура, Open Hardware
• Слом застарелых стереотипов о том, как должен выглядеть десктоп, и каковы задачи, на нем решаемые. Появление сразу букета новых решений (спасибо, GNOME 3, ты показал пользователям, что существует много других вариантов!) и нового класса мобильного оборудования.

Все это приводит к тому, что коммьюнити Fedora Project обязано меняться, подстраиваться под разработчиков нового оборудования и его пользователей, участвовать в мероприятиях по Open Hardware, включать самое последнее ПО для виртуализации и облаков, развивать новейшие десктопные технологии, не забывая предоставлять возможность выбора, создавать механизмы для "кастомизации" дистрибутива, желательно без установки gcc и rpmbuild, идти на компромиссы при установке и обновлению ПО. Кое-что у нас получается, кое-что пока не очень (особенно по инфраструктуре, где мы всегда рады новым добровольцам), но главное - у нас никакой стабильности никакого застоя. Наоборот - градус только растет, и веселье только начинается. Присоединяйтесь к нам, т.к. во-1 сейчас у нас для начинающих очень много возможностей увековечить себя, а во-2 мы играем ключевую роль в принятии решений о том, каким будет Open Source в будущем!