Подготовка релизов FreeBSD

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

товарные знаки

FreeBSD является зарегистрированным товарным знаком Фонда FreeBSD.

Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium и Xeon это торговые марки или зарегистрированные торговые марки Intel Corporation или ее дочерних компаний в Соединенных Штатах и других странах.

Многие из обозначений, используемые производителями и продавцами для обозначения своих продуктов, заявляются в качестве товарных знаков. Когда такие обозначения появляются в этом документе, и Проекту FreeBSD известно о товарном знаке, к обозначению добавляется знак “™” или “®”.

Аннотация

В этой статье описывается подход, который используется группой подготовки релизов FreeBSD для создания качественных версий Операционной Системы FreeBSD. В ней детально описывается методология, используемая для официальных релизов FreeBSD и рассказывается об инструментах, доступных тем, кто интересуется созданием модифицированных релизов FreeBSD для тиражирования внутри организации или в коммерческих целях.


1. Введение

Разработка FreeBSD представляет собой весьма открытый процесс. FreeBSD составляется в результате общих усилий тысяч людей по всему миру. Проект FreeBSD предоставляет анонимный публичный доступ по протоколу CVS[1], так что любой может получить доступ к журналу изменений, разницам (патчам) между ветками разработки и другим продвинутым возможностям, которые даёт строгое управление исходным кодом. Это сильно помогает в привлечении к FreeBSD всё большего количества талантливых разработчиков. Однако, и я думаю, что все со мной согласятся, наступит хаос, если доступ по записи будет открыт всем в Internet. Поэтому только "избранная" группа примерно из 300 человек имеет доступ по записи в CVS-хранилище. Эти коммиттеры[5] отвечают в целом за разработку FreeBSD. Выбираемая из самых заслуженных разработчиков группа правления[6] обеспечивает некоторый уровень управления проектом.

Темп разработок, ведущихся во FreeBSD, оставляет мало времени на тщательную доводку системы до качества продуктивного релиза. Для решения этой проблемы разработка ведётся в два параллельных потока. Основной веткой разработки является HEAD, она же основная линия нашего дерева CVS, известная также под именем "FreeBSD-CURRENT" или, для краткости, "-CURRENT".

Поддерживается и более стабильная ветка, известная как "FreeBSD-STABLE" или, для краткости, "-STABLE". Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются при помощи CVSup[2] на зеркала по всему миру. FreeBSD-CURRENT[7] является "передним краем" работ над FreeBSD, через который попадают все изменения в системе. FreeBSD-STABLE является веткой разработки, из которой создаются основные релизы. В эту ветку изменения попадают разными путями, и предполагается, что сначала они попали в FreeBSD-CURRENT, где были тщательно протестированы сообществом наших пользователей.

В промежутке между релизами машинами Проекта FreeBSD, выделенными для построения системы, ежемесячно автоматически собираются снэпшоты, которые доступны для закачки по адресу ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. Общедоступность снэпшотов бинарных релизов, а также желание сообщества наших пользователей отслеживать работу над -STABLE при помощи CVSup и “make world”[7] помогает поддержать весьма хорошее качество FreeBSD-STABLE, даже до выполнения мероприятий проверки качества, предваряющих выпуск основных релизов.

В процессе выпуска релиза пользователи постоянно присылают сообщения об ошибках и пожелания по расширению функциональности. Сообщения о проблемах попадают в нашу базу данных GNATS[8] по электронной почте, посредством утилиты send-pr(1) или через Web-интерфейс, доступный по адресу http://www.FreeBSD.org/send-pr/.

Для удовлетворения наших самых консервативно настроенных пользователей, начиная с FreeBSD 4.3, появились ветки для отдельных релизов. Эти ветки создаются вскоре после того, как выпускается окончательный релиз. После его выхода в ветку релиза помещаются только самые критичные исправления и добавления, касающиеся безопасности. Кроме обновлений исходных текстов посредством CVS, для систем веток RELENG_X_Y имеются и бинарные наборы патчей.

1.1. Что обсуждается в данном документе?

В последующих главах этой статьи обсуждаются:

Процесс выпуска релиза

Различные этапы процесса подготовки релиза вплоть до построения актуальной системы.

Построение релизов

Процесс сборки.

Расширяемость

Как базовый релиз может быть расширен третьими сторонами.

Уроки, извлечённые из FreeBSD 4.4

Некоторые из уроков, полученных при выпуске релиза FreeBSD 4.4.

Направления будущих работ

Направления будущих работ.

2. Процесс выпуска релиза

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

2.1. Просмотр кода

За тридцать дней до предполагаемого релиза хранилище исходных текстов переводится в режим "стабилизации кода". В этот период все изменения в дереве -STABLE должны подтверждаться Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>. В первый 15-дневный период разрешены следующие типы изменений:

  • Исправления ошибок.

  • Обновление документации.

  • Исправления любого характера, касающиеся безопасности.

  • Незначительные исправления в драйверах устройств, такие, как, например, добавление новых ID устройств.

  • Любые другие изменения, которые одобряет группа подготовки релиза, с учётом потенциального риска.

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

2.2. Контрольный список для проверки окончательного релиза

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

2.2.1. Создание ветки релиза

Как сказано во вводной части, ветка RELENG_X_Y является сравнительно новым добавлением в нашей методологии подготовки релизов. Первым шагом в создании этой ветки является проверка того, что вы работаете с самой последней версией исходных текстов RELENG_X, из которой вы хотите создать новую ветку.

/usr/src# cvs update -rRELENG_4 -P -d

Следующим шагом является создание тэга точки ответвления, чтобы диффы облегчили работу с началом ветки в CVS:

/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src

После этого создаётся тэг новой ветки по команде:

/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src

Использование тэгов RELENG_* разрешено только менеджерам CVS и участникам группы по выпуску релизов.

"Тэгом " в понятии CVS называют метку, которая идентифицирует исходный текст в некоторый момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в будущем тот, кто строит релиз, всегда сможет воспользоваться тем же самым кодом, что использовался нами для создания официальных релизов Проекта FreeBSD.

Ветви разработки FreeBSD
Ветка FreeBSD 3.x STABLE
Ветка FreeBSD 4.x STABLE
Ветка FreeBSD 5.x STABLE
Ветка FreeBSD 6.x STABLE
Ветка FreeBSD 7.x STABLE
Ветка FreeBSD 8.x STABLE
Ветка FreeBSD 9.x STABLE

2.2.2. Увеличение номера версии

Перед тем, как окончательный релиз будет помечен, построен и выпущен, необходимо модифицировать следующие файлы, отразив в них корректную версию FreeBSD:

  • doc/ru_RU.KOI8-R/books/handbook/mirrors/chapter.xml

  • doc/en_US.ISO8859-1/books/porters-handbook/book.xml

  • doc/shared/xml/freebsd.ent

  • src/Makefile.inc1

  • src/UPDATING

  • src/gnu/usr.bin/groff/tmac/mdoc.local

  • src/release/Makefile

  • src/release/doc/en_US.ISO8859-1/shared/xml/release.dsl

  • src/release/doc/shared/examples/Makefile.relnotesng

  • src/release/doc/shared/xml/release.ent

  • src/shared/examples/cvsup/standard-supfile

  • src/sys/conf/newvers.sh

  • src/sys/sys/param.h

  • src/usr.sbin/pkg_install/add/main.c

  • www/en/docs/man.xml

  • www/en/cgi/ports.cgi

  • ports/Tools/scripts/release/config

Новый релиз должен быть также отражён в файлах замечаний к релизу и информации о замеченных ошибках (в ветке релиза), а файлы соответствующим образом обрезаны (в ветке stable/current):

  • src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml

  • src/release/doc/en_US.ISO8859-1/errata/article.xml

Утилита Sysinstall должна быть обновлена и указывать количество доступных портов и объём дискового пространства, требуемого для Коллекции Портов[4]. На данный момент эта информация хранится в файле src/usr.sbin/sysinstall/dist.c.

После построения релиза для оповещения мирового сообщества о выпуске релиза необходимо обновить некоторые файлы.

  • doc/shared/images/articles/releng/branches-relengX.pic

  • www/shared/xml/advisories.xml

  • www/shared/xml/includes.release.xml

  • www/shared/xml/includes.release.xsl

  • www/en/releases/*

  • www/en/releng/index.xml

  • www/en/news/news.xml

  • www/en/search/web.atoz

  • src/shared/misc/bsd-family-tree

2.2.3. Подготовка новой старшей релиз ветки (RELENG_X)

Когда новая старшая релиз ветка, такая как RELENG_6 ответвляется из HEAD, некоторые дополнительные файлы должны быть обновлены перед тем, как релизы будут созданы из этой новой ветки.

  • src/shared/examples/cvsup/stable-supfile - когда применимо, должен быть обновлен, чтобы указывать на новую -STABLE ветку.

2.2.4. Создание тэгов релиза

При готовности окончательного релиза следующая команда создаст тэг RELENG_4_8_0_RELEASE.

/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src

Менеджеры документации и портов отвечают за внесение тэга в соответствующие ветки с тэгом RELEASE_4_8_0.

Иногда в последний момент, уже после создания последних тэгов может потребоваться внесение исправлений. На практике это не является проблемой, так как CVS позволяет выполнять манипуляции с тэгами по команде cvs tag -d tagname filename. Очень важно, чтобы все последние изменения были помечены соответствующим тэгом, как часть релиза. Релизы FreeBSD должны быть всегда повторяемыми. Локальные изменения в параметры окружения выпускающего релиз недопустимы.

3. Построение релизов

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

3.1. make release

Для успешного построения релиза вы должны сначала заполнить каталог /usr/obj, запустив команду make world или просто make buildworld. Цель, выполняемая для построения релиза, требует корректного задания нескольких переменных, используемых при его сборке:

  • CHROOTDIR - Каталог, используемый в среде с изменённой корневой файловой системой при построении полного релиза.

  • BUILDNAME - Наименование строящегося релиза.

  • CVSROOT - Местонахождение CVS-хранилища.

  • RELEASETAG - Тэг CVS, соответствующий релизу, который вы собираетесь строить.

Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете зеркалировать одно из них при помощи CVSup. Поставляемый sup-файл, /usr/shared/examples/cvsup/cvs-supfile, может служить хорошей отправной точкой для зеркалирования хранилища CVS.

Если RELEASETAG опущен, то релиз будет строиться из ветки HEAD (известной как -CURRENT). Релизы, строящиеся из этой ветки обычно называют "снэпшотами -CURRENT".

Для настройки построения релиза существует много других переменных Большинство из этих переменных описаны в начале файла src/release/Makefile. Точная команда, служащая для построения официального релиза FreeBSD 4.7 (x86) такова:

make release CHROOTDIR=/local3/release \
	BUILDNAME=4.7-RELEASE \
	CVSROOT=/host/cvs/usr/home/ncvs \
	RELEASETAG=RELENG_4_7_0_RELEASE

Makefile для релиза может быть разбит на несколько различных шагов.

  • Создание чистого системного окружения в отдельной иерархии каталогов по команде “make installworld”.

  • Выгрузка из CVS чистой версии исходных текстов системы, документации и портов в иерархию для построения релиза.

  • Создание копии /etc и /dev в окружении с изменённым корнем файловой системы.

  • Смена корневой файловой системы на иерархию построения релиза, чтобы избежать влияния внешнего окружения на построение.

  • Выполнение make world в окружении с изменённой корневой файловой системой.

  • Построение бинарных файлов для работы с Kerberos.

  • Построение ядра GENERIC.

  • Создание промежуточного дерева каталогов, где будут строиться бинарные файлы и формироваться дистрибутивы.

  • Построение и установка инструментов для работы с документацией, необходимых для преобразования исходных текстов документации (SGML) в формат HTML и текстовые документы, которые сопутствуют релиз.

  • Построение и установка актуальной документации (руководства пользователей, учебники, замечания к релизу, перечень аппаратной совместимости и так далее.)

  • Построение "свёрнутых" бинарных файлов, используемых на установочных дискетах.

  • Подготовка дистрибутивных архивов бинарных файлов и исходных текстов.

  • Создание загрузочного носителя и "fixit"-дискеты.

  • Создание иерархии для установки при помощи FTP.

  • (опционально) Создание образов ISO для носителей CDROM/DVD.

Для получения более полной информации об инфраструктуре построения релизов, пожалуйста, обратитесь к справочной странице по release(7).

Важно, чтобы из файла /etc/make.conf были удалены все установки, специфичные для конкретного хоста. К примеру, будет глупо распространять бинарные файлы, построенные на системе с переменной CPUTYPE, указывающей на определённый тип процессора.

3.2. Программное обеспечение третьих лиц ("ports")

Коллекция портов FreeBSD содержит более 36000 программных пакетов сторонних разработчиков, которые доступны для FreeBSD. За поддержку целостности дерева портов, которое может использоваться для создания бинарных пакетов, поставляемых с официальными релизами FreeBSD, отвечает Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org>.

Рассмотрение работ с нашей коллекцией пакетов сторонних разработчиков при подготовке релизов выходит за рамки этого документа. Этот вопрос глубоко рассмотрен в отдельной статье, The Release Engineering of Third Party Packages.

3.3. ISO с релизами

Начиная с FreeBSD 4.4, Проект FreeBSD принял решение распространять все четыре образа ISO, ранее продаваемые через BSDi/Wind River Systems/FreeBSD Mall как "официальные" дистрибутивы на CDROM. Каждый из четырёх дисков должен содержать файл README.TXT, описывающий содержимое диска, файл CDROM.INF, в котором находятся мета-данные о диске для того, чтобы sysinstall(8) мог проверять и использовать содержимое, а также файл filename.txt, содержащий перечень содержимого на диске. Этот перечень может быть создан простой командой:

/stage/cdrom# find . -type f | sed -e 's/^\.\///' | sort > filename.txt

Специфичные требования для каждого CD описываются ниже.

3.3.1. Диск 1

Первый диск практически полностью создаётся командой make release. Единственным изменением, которое нужно внести в каталог disc1, является добавление подкаталога tools, а также перенос максимально возможного количества программных пакетов сторонних разработчиков, которые поместятся на диск. Каталог tools содержит программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск нужно сделать загрузочным, чтобы пользователям современных ПК не нужно было создавать установочные дискеты.

Если в релиз необходимо включить специализированное ядро, то необходимо модифицировать sysinstall(8) и release(7), добавив в них инструкции по установке. Соответствующий код находится в src/release и src/usr.sbin/sysinstall. В частности, в src/usr.sbin/sysinstall необходимо будет редактировать src/release/Makefile, dist.c, dist.h, menus.c, install.c и Makefile. Также может потребоваться обновить sysinstall.8.

3.3.2. Диск 2

Второй диск также в основном создаётся по команде make release. Он содержит "живую файловую систему", которую можно использовать из sysinstall(8) для исправления процесса установки FreeBSD. Этот диск должен быть загрузочным и содержать также упакованную копию хранилища CVS в каталоге CVSROOT и демонстрационные версии коммерческого программного обеспечения в каталоге commerce.

3.3.3. Диски 3 и 4

Оставшиеся два диска содержат дополнительные программные пакеты для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы отдельный пакет и все его зависимости находились на одном и том же диске. Дополнительная информация о создании этих дисков находится в статье The Release Engineering of Third Party Packages.

3.3.4. Поддержка нескольких дисков

Sysinstall поддерживает установку пакетов с нескольких дисков. Для это нужно, чтобы на каждом диске был файл INDEX, содержащий названия всех пакетов со всех дисков, с дополнительным полем, указывающем на каком диске содержится данный конкретный пакет. Также, на каждом диске, в файле cdrom.inf должна быть указана переменная CD_VOLUME для того, чтобы sysinstall мог определить какой этой диск. Когда пользователь будет пытаться установить пакет, которого нет на текущем диске, sysinstall выдаст запрос на вставку соответствующего диска.

4. Распространение

4.1. Серверы FTP

После того, как релиз был тщательно протестирован и подготовлен к распространению, должен быть обновлён главный FTP-сервер. Все официальные общедоступные серверы FTP-серверы FreeBSD являются зеркалами главного сервера, открытого только другим серверам FTP. Этот сервер известен под именем ftp-master. Когда релиз готов, на сервере ftp-master должны быть изменены следующие строки:

/pub/FreeBSD/releases/arch/X.Y-RELEASE/

Установочный каталог FTP, получаемый по команде make release.

/pub/FreeBSD/ports/arch/packages-X.Y-release/

Полный комплект построенных пакетов для этого релиза.

/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools

Символическая ссылка на ../../../tools.

/pub/FreeBSD/releases/arch/X.Y-RELEASE/packages

Символическая ссылка на ../../../ports/arch/packages-X.Y-release.

/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso

ISO-образы. Здесь "*" это disc1, disc2 и так далее. Только если здесь есть disc1 и альтернативный первый установочный CD (например, обрезанная установка без оконной системы), то здесь может быть также и mini.

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

Может пройти от нескольких часов до двух дней между тем, как обновится ftp-master, и на основной массе FTP-серверов 1-го уровня появится новое программное обеспечение, в зависимости от того, в тоже самое ли время пакет был загружен. Обязательно, чтобы выпускающие релиз координировали свои действия с Администраторы зеркальных сайтов FreeBSD до того, как объявлять об общедоступности нового программного обеспечения с серверов FTP. В идеальном случае набор пакетов к релизу должен быть загружен по крайней мере за четыре дня до момента выпуска релиза. Релиз должен быть загружен в промежутке от 24 до 48 часов до момента выхода запланированного релиза с выключенными полномочиями "other". Это позволит зеркалирующим серверам сгрузить его, но никто не сможет получить его с зеркальных серверов. В момент выхода релиза должно быть послано сообщение в адрес Администраторы зеркальных сайтов FreeBSD, говорящее о том, что релиз выпущен и наступило время для открытия доступа на зеркальных серверах. Обязательно вместе со временем укажите и часовой пояс, например, относительно GMT.

4.2. Тиражирование CD-ROM

Вскоре появится: Советы по передаче ISO-образов FreeBSD на тиражирование и применяемые меры по контролю качества.

5. Расширяемость

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

5.1. Создание модифицированных загрузочных дискет

Во многих местах имеются сложные условия, которые требуют размещения дополнительных модулей ядра или пользовательских инструментов на установочные дискеты. "Быстрым и неаккуратным" способом сделать это является изменение промежуточного каталога в существующей иерархии при выполнении make release:

  • Примените патчи или добавьте дополнительные файлы в каталог построения релиза с изменённых корнем файловой системы.

  • rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59]

  • перестройте sysinstall(8), ядро и остальные части системы, которые коснулись ваши изменения.

  • chroot ${CHROOTDIR} ./mk floppies

Дискеты нового релиза будут находиться в ${CHROOTDIR}/R/stage/floppies.

Либо может быть вызвана цель boot.flp построения или скрипт создания файловой системы, src/release/scripts/doFS.sh, которые может быть вызван напрямую.

Локальные патчи могут быть также приложены к построению релиза при помощи задания переменной LOCAL_PATCH при выполнении make release.

5.2. Скрипты sysinstall

Инструмент установки и настройки системы FreeBSD, sysinstall(8), может работать по сценарию, полезному для автоматизированной установки в больших компаниях. Эта функциональность может использоваться совместно с технологией Intel® PXE[12] для первоначальной установки систем из сети, или с модифицированными загрузочными дискетами со скриптами sysinstall. Пример скрипта для sysinstall доступен в дереве CVS в виде файла src/release/sysinstall/install.cfg.

6. Уроки, извлечённые из FreeBSD 4.4

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

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

7. Направления будущих работ

Нашим работам по подготовке релизов жизненно важно расти вместе с увеличением количества пользователей системы. Вместе с этим мы очень плотно работаем над документированием действий, выполняемых при выпуске релизов FreeBSD.

  • Параллелизм - некоторые этапы построения релиза на самом деле выполнять параллельно "затруднительно". Большинство выполняемых задач весьма интенсивно работают с I/O, так что для ускорения процесса make release наличие нескольких высокоскоростных дисков гораздо более важно, чем использование нескольких процессоров. Если для различных иерархий в chroot(2)-окружении используется несколько дисков, то извлечение из CVS деревьев ports и doc может выполняться одновременно с командой make world на другом диске. Использование RAID-решений (аппаратных или программных) может значительно сократить общее время построения.

  • Кроссплатформенное построение релизов - Построить релиз для IA-64 или Alpha на x86-оборудовании? make TARGET=ia64 release.

  • Тестирование - Нам нужна улучшенная автоматизированная система тестирования корректности для FreeBSD.

  • Инструменты установки - Наша программа установки давно пережила свой век. В разработке находятся несколько проектов, которые должны дать улучшенную технологию установки. Одним из таких проектов был libh, целью которого было создание новой интеллектуальной технологии работы с пакетами и программы установки с GUI.

8. Благодарности

Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он дал мне возможность взять под свою ответственность некоторые части процесса подготовки релиза 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[13], NetBSD Project[10] и замечаний Джона Балдвина (John Baldwin) по предлагаемому процессу подготовки релизов[11].

9. Справочная литература

(1) CVS - Concurrent Versions System http://www.cvshome.org

(2) CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup

(4) Коллекция портов FreeBSD http://www.FreeBSD.org/ports

(6) Правление FreeBSD https://www.FreeBSD.org/administration/#t-core

(8) GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats

(9) Статистика FreeBSD PR FreeBSD PR Statistics http://www.FreeBSD.org/prstats/

(10) NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html

(11) John Baldwin’s FreeBSD Release Engineering Proposal http://people.FreeBSD.org/~jhb/docs/releng.txt

(12) PXE Jumpstart Guide PXE Guide

(13) Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD


Изменено: 3 ноября 2021 г. by Sergio Carlavilla Delgado