Устаревшая разработка релизов FreeBSD

Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion ^[1] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право записи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти коммиттеры FreeBSD^[2] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Избранная группа разработчиков — Core Team^[3] — обеспечивает некоторый уровень руководства проектом.

Быстрый темп разработки FreeBSD делает основную ветку разработки непригодной для повседневного использования широкой публикой. В частности, требуются усилия по стабилизации для доведения системы разработки до релиза производственного качества. Для решения этого конфликта разработка продолжается по нескольким параллельным направлениям. Основная ветка разработки — это HEAD или trunk нашего дерева Subversion, известная как "FreeBSD-CURRENT" или сокращённо "-CURRENT".

Набор более стабильных ветвей поддерживается под названием "FreeBSD-STABLE" или сокращённо "-STABLE". Все ветви находятся в главном хранилище Subversion, которое поддерживается проектом FreeBSD. FreeBSD-CURRENT — это "передний край" разработки FreeBSD, куда сначала попадают все новые изменения. FreeBSD-STABLE — это ветвь разработки, на основе которой выпускаются основные релизы. Изменения попадают в эту ветвь с другой скоростью и с общим предположением, что они сначала попали в FreeBSD-CURRENT и были тщательно протестированы сообществом пользователей.

Термин stable в названии ветки относится к предполагаемой стабильности бинарного интерфейса приложений (ABI), которую гарантирует проект. Это означает, что пользовательское приложение, скомпилированное на более старой версии системы из той же ветки, будет работать на более новой системе из той же ветки. Стабильность ABI значительно улучшилась по сравнению с предыдущими выпусками. В большинстве случаев бинарные файлы со старых систем STABLE работают без изменений на более новых системах, включая HEAD, при условии, что не используются интерфейсы управления системой.

В промежуточный период между выпусками еженедельные снимки состояния системы автоматически создаются сборщиками FreeBSD Project и доступны для загрузки по адресу https:/download.FreeBSD.org/snapshots/. Широкое распространение бинарных снимков выпусков, а также склонность нашего сообщества пользователей следить за разработкой -STABLE с помощью Subversion и команды “make buildworld” ^[4] помогает поддерживать FreeBSD-STABLE в очень надежном состоянии даже до того, как активизируются мероприятия по обеспечению качества перед основным выпуском.

Помимо снимков установочных ISO, также предоставляются еженедельные образы виртуальных машин для использования с VirtualBox, qemu или другим популярным эмуляционным программным обеспечением. Образы виртуальных машин можно загрузить с https://download.FreeBSD.org/snapshots/VM-IMAGES/.

Образы виртуальных машин сжаты с помощью xz(1) и занимают примерно 150 МБ, а при подключении к виртуальной машине содержат разреженную файловую систему размером 10 ГБ.

Отчеты об ошибках и запросы функций постоянно отправляются пользователями в течение цикла выпуска. Сообщения о проблемах вносятся в нашу базу данных Bugzilla через веб-интерфейс, доступный по адресу https://www.freebsd.org/support/bugreports/.

Для обслуживания наиболее консервативных пользователей, начиная с FreeBSD 4.3, были введены индивидуальные ветки релизов. Эти ветки создаются незадолго до выпуска финального релиза. После выхода релиза на ветку вносятся только самые критические исправления безопасности и дополнения. Помимо обновлений исходного кода через Subversion, доступны бинарные патч-наборы для поддержания актуальности систем на ветках releng/X.Y.

Новые выпуски FreeBSD выходят из ветки -STABLE примерно с интервалом в четыре месяца. Процесс выпуска FreeBSD начинает набирать обороты за 70-80 дней до предполагаемой даты выпуска, когда инженер выпуска отправляет электронное письмо в списки рассылки разработчиков, напоминая им, что у них осталось всего 15 дней для интеграции новых изменений до заморозки кода. В это время многие разработчики выполняют так называемые "MFC-проверки".

MFC означает "Merge From CURRENT" и описывает процесс переноса проверенного изменения из нашей ветки разработки -CURRENT в ветку -STABLE. Политика проекта требует, чтобы любое изменение сначала было применено к основной ветке, а затем перенесено в ветки -STABLE после достаточного внешнего тестирования пользователями -CURRENT (ожидается, что разработчики тщательно проверят изменение перед внесением в -CURRENT, но невозможно для одного человека проверить все варианты использования универсальной операционной системы). Минимальный срок для MFC составляет 3 дня, который обычно используется только для тривиальных или критических исправлений ошибок.

Сборка "релизов" FreeBSD может быть выполнена любым пользователем, имеющим быстрый компьютер и доступ к репозиторию исходного кода. (Это должно быть доступно каждому, так как мы предоставляем доступ через Subversion! Подробности см. в разделе Subversion в Руководстве.) Единственное специальное требование — доступность устройства md(4). Если устройство не загружено в ваше ядро, то модуль ядра должен автоматически загрузиться при выполнении mdconfig(8) во время этапа создания загрузочного носителя. Все необходимые инструменты для сборки релиза доступны в репозитории Subversion в src/release. Эти инструменты предназначены для обеспечения единообразного способа сборки релизов FreeBSD. Полный релиз может быть собран всего одной командой, включая создание ISO-образов, пригодных для записи на CDROM или DVD, а также каталога для установки по FTP. release(7) полностью документирует скрипт src/release/generate-release.sh, который используется для сборки релиза. generate-release.sh является обёрткой для цели Makefile: make release.

Хотя FreeBSD представляет собой законченную операционную систему, ничто не обязывает вас использовать её именно в том виде, в каком мы упаковали её для распространения. Мы постарались разработать систему максимально расширяемой, чтобы она могла служить платформой для создания других коммерческих продуктов. Единственное «правило», которое у нас есть на этот счёт, — если вы собираетесь распространять FreeBSD с существенными изменениями, мы рекомендуем документировать ваши улучшения! Сообщество FreeBSD может оказывать поддержку только пользователям того программного обеспечения, которое мы предоставляем. Мы, безусловно, приветствуем инновации, такие как продвинутые инструменты установки и администрирования, но не можем отвечать на вопросы о них.

Процесс разработки релиза 4.4 официально начался 1 августа 2001 года. После этой даты все коммиты в ветку RELENG_4 FreeBSD должны были быть явно одобрены Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>. Первый релиз-кандидат для архитектуры x86 был выпущен 16 августа, за ним последовали ещё 4 релиз-кандидата, что привело к финальному релизу 18 сентября. Сотрудник по безопасности был очень вовлечён в последнюю неделю процесса, так как несколько проблем безопасности было обнаружено в ранних релиз-кандидатах. Всего за чуть более месяца было отправлено более 500 писем Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>.

Наше сообщество пользователей ясно дало понять, что безопасность и стабильность выпуска FreeBSD не должны приноситься в жертву из-за самостоятельно установленных сроков или целевых дат выпуска. Проект FreeBSD значительно вырос за время своего существования, и необходимость стандартизированных процедур управления выпусками никогда не была столь очевидной. Это станет ещё более важным по мере переноса FreeBSD на новые платформы.

Для обеспечения масштабирования наших процессов релиз-инжиниринга с растущей пользовательской базой мы прилагаем значительные усилия по документированию процедур, связанных с созданием выпусков FreeBSD.

Я хотел бы поблагодарить Джордана Хаббарда за предоставленную мне возможность взять на себя часть обязанностей по управлению выпусками для FreeBSD 4.4, а также за всю его работу на протяжении многих лет, которая сделала FreeBSD такой, какая она есть сегодня. Конечно, выпуск не состоялся бы без всей работы, связанной с выпуском, выполненной Satoshi Asami <asami@FreeBSD.org>, Steve Price <steve@FreeBSD.org>, Bruce A. Mah <bmah@FreeBSD.org>, Nik Clayton <nik@FreeBSD.org>, David O’Brien <obrien@FreeBSD.org>, Kris Kennaway <kris@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org> и остальным сообществом разработчиков FreeBSD. Я также хотел бы поблагодарить Rodney W. Grimes <rgrimes@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org> и других, кто работал над инструментами управления выпусками в самые ранние дни FreeBSD. На эту статью повлияли документы по управлению выпусками от CSRG ^[7], проекта NetBSD ^[8] и заметки Джона Болдуина с предложениями по процессу управления выпусками. ^[9]