diff --git a/ru_RU.KOI8-R/articles/releng/article.sgml b/ru_RU.KOI8-R/articles/releng/article.sgml new file mode 100644 index 0000000000..a2ce60279b --- /dev/null +++ b/ru_RU.KOI8-R/articles/releng/article.sgml @@ -0,0 +1,1030 @@ + + + + +%authors; + +%teams; + +%mailing-lists; + +%man; + +%freebsd; + +%trademarks; +The Release Engineering of Third Party Packages'> +]> + +
+ Подготовка релизов FreeBSD + + + + + + Ноябрь 2001 + + BSDCon Europe + + + + + Murray + + Stokely + + + Я участвовал в разработке продуктов на основе FreeBSD с + 1997 года в компаниях Walnut Creek CDROM, BSDi, а теперь Wind River + Systems. FreeBSD 4.4 была первым официальным релизом FreeBSD, в + выпуске которого я принимал значительное участие. + + + +
+ murray@FreeBSD.org + + +
+ + + + + $FreeBSD$ + + + &tm-attrib.freebsd; + &tm-attrib.cvsup; + &tm-attrib.intel; + &tm-attrib.xfree86; + &tm-attrib.general; + + + + В этой статье описывается подход, который используется группой + подготовки релизов FreeBSD для создания качественных версий + Операционной Системы FreeBSD. В ней детально описывается методология, + используемая для официальных релизов FreeBSD и рассказывается об + инструментах, доступных тем, кто интересуется созданием + модифицированных релизов FreeBSD для тиражирования внутри организации + или в коммерческих целях. + + + + + + + Введение + + Разработка FreeBSD представляет собой весьма открытый процесс. + FreeBSD составляется в результате общих усилий тысяч людей по всему миру. + Проект FreeBSD предоставляет анонимный публичный доступ по протоколу + CVS[1], так что любой может получить доступ к журналу + изменений, разницам (патчам) между ветками разработки и другим + продвинутым возможностям, которые даёт строгое управление исходным кодом. + Это сильно помогает в привлечении к FreeBSD всё большего количества + талантливых разработчиков. Однако, и я думаю, что все со мной + согласятся, наступит хаос, если доступ по записи будет открыт всем в + Internet. Поэтому только избранная группа примерно из + 300 человек имеет доступ по записи в CVS-хранилище. + Эти коммиттеры[6] отвечают в целом за разработку + FreeBSD. Выбираемая из самых заслуженных разработчиков группа + правления[7] обеспечивает некоторый уровень управления + проектом. + + Темп разработок, ведущихся во FreeBSD, оставляет мало времени на тщательную + доводку системы до качества продуктивного релиза. Для решения этой + проблемы разработка ведётся в два параллельных потока. Основной веткой + разработки является HEAD, она же основная + линия нашего дерева CVS, известная также под именем + FreeBSD-CURRENT или, для краткости, + -CURRENT. + + Поддерживается и более стабильная ветка, известная как + FreeBSD-STABLE или, для краткости, -STABLE. + Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются + при помощи CVSup[2] на + зеркала по всему миру. FreeBSD-CURRENT[8] является передним + краем работ над FreeBSD, через который попадают все изменения в + системе. FreeBSD-STABLE является веткой разработки, из которой создаются + основные релизы. В эту ветку изменения попадают разными путями, и + предполагается, что сначала они попали в FreeBSD-CURRENT, где были + тщательно протестированы сообществом наших пользователей. + + В промежутке между релизами машинами Проекта FreeBSD, выделенными для + построения системы, каждую ночь автоматически собираются снэпшоты, + которые доступны для сгрузки по адресу ftp://stable.FreeBSD.org/. Общедоступность + снэпшотов бинарных релизов, а также желание сообщества наших + пользователей отслеживать работу над -STABLE при помощи CVSup и + make world[8] + помогает поддержать весьма хорошее качество FreeBSD-STABLE, даже до + выполнения мероприятий проверки качества, предваряющих выпуск основных + релизов. + + В процессе выпуска релиза пользователи постоянно присылают сообщения + об ошибках и пожелания по расширению функциональности. Сообщения о + проблемах попадают в наду базу данных GNATS[9] по электронной почте, посредством + утилиты &man.send-pr.1; или через Web-интерфейс, доступный по адресу + . Кроме + множества различных технических списков рассылки о FreeBSD, по адресу + &a.qa; можно найти форум для обсуждения улучшений в + процессе выпуска релизов. + + Для удовлетворения наших самых консервативно настроенных + пользователей, начиная с FreeBSD 4.3, появились ветки для отдельных + релизов. Эти ветки создаются вскоре после того, как выпускается + окончательный релиз. После его выхода в ветку релиза помещаются только + самые критичные исправления и добавления, касающиеся безопасности. Кроме + обновлений исходных текстов посредством CVS, для систем веток + RELENG_X_Y + имеются и бинарные наборы патчей. + + В обсуждаются различные этапы процесса + подготовки релиза вплоть до построения актуальной системы, а описывает сам процесс сборки. описывает, как базовый релиз может быть расширен + третьими сторонами, а проясняет + некоторые из уроков, полученных при выпуске релиза FreeBSD 4.4. Наконец, + в описывается будущие направления работ. + + + + + Процесс выпуска релиза + + Новые релизы FreeBSD выпускаются из ветки -STABLE с интервалом + примерно в четыре месяца. Процесс выпуска релизов FreeBSD начинается за + 45 дней до предполагаемой даты релиза с того, что ответственный за релиз + посылает сообщение по электронной почте в адрес списков рассылки для + разработчиков, чтобы напомнить последним о наличи всего лишь 15 дней на + внемение новых изменений до момента заморозки кода. В этот период многие + разработчики выполняют действия, известные как + MFC-переносы. MFC означает + Merge From CURRENT (перенос из CURRENT) и описывает + процесс переноса протестированных изменений из нашего дерева разработки + -CURRENT в наше дерево -STABLE. + + + Просмотр кода + + За тридцать дней до предполагаемого релиза хранилище исходных + текстов переводится в режим стабилизации кода. В этот + период все изменения в дереве -STABLE должны подтверждаться &a.re;. + В этот 15-дневный период разрешены следующие типы изменений: + + + + Исправления ошибок. + + + + Обновление документации. + + + + Исправления любого характера, касающиеся безопасности. + + + + Незначительные исправления в драйверах устройств, такие, как, + например, добавление новых ID устройств. + + + + Любые другие изменения, которые одобряет группа подготовки + релиза, с учётом потенциального риска. + + + + После первых 15 дней стабилизации кода выпускается + предварительный релиз, предначенный для широкого + тестирования, а код переводится в состояние заморозки, + когда становится гораздо труднее доказывать необходимость внесения + новых изменений в систему, если они не касаются исправления серьёзных + ошибок или информационной безопасности. Во время заморозки кода каждую + неделю выпускается не менее одной предварительной версии релиза, до тех + пор, пока не будет готов окончательный вариант релиза. В дни, + предшествующие выпуску окончательного релиза, группа его подготовки + работает в постоянном контакте со службой безопасности и людьми, + поддерживающими документацию и порты, чтобы обеспечить доступность всех + компонентов, необходимых для успешного выпуска релиза. + + + + Контрольный список для проверки окончательного релиза + + После того, как для широкого тестирования было выпущено несколько + предварительных релизов и все основные проблемы были решены, может + начаться процесс шлифовки окончательного релиза. + + + Создание ветки релиза + + Как сказано во вводной части, ветка + RELENG_X_Y + является сравнительно новым добавлением в нашей методологии + подготовки релизов. Первым шагом в создании этой ветки является + проверка того, что вы работаете с самой последней версией исходных + текстов RELENG_X, из + которой вы хотите создать новую ветку. + + /usr/src&prompt.root; cvs update -rRELENG_4 -P -d + + Следующим шагом является создание тэга точки + ответвления, чтобы диффы облегчили работу с началом ветки в CVS: + + /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src + + После этого создаётся тэг новой ветки по команде: + + /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src + + + Использование тэгов + RELENG_* разрешено + только менеджерам CVS и участникам группы по выпуску + релизов. + + + + Тэгом в понятии CVS + называют метку, которая идентифицирует исходный текст в некоторый + момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в + будущем тот, кто строит релиз, всегда сможет воспользоваться тем же + самым кодом, что использовался нами для создания официальных + релизов Проекта FreeBSD. + + + + + + + + + &branches.ascii; + + + + Ветки разработки FreeBSD + + + + + + Увеличение номера версии + + Перед тем, как окончательный релиз будет помечен, построен и + выпущен, необходимо модифицировать следующие файлы, отразив в них + корректную версию FreeBSD: + + + + doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml + + + + doc/en_US.ISO8859-1/books/porters-handbook/book.sgml + + + + doc/share/sgml/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/share/sgml/release.dsl + + + + src/release/doc/share/examples/Makefile.relnotesng + + + + src/release/doc/share/sgml/release.ent + + + + src/share/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.sgml + + + + www/en/cgi/ports.cgi + + + + ports/Tools/scripts/release/config + + + + Новый релиз должен быть также отражён в файлах замечаний к релизу + и информации о замеченных ошибках (в ветке релиза), а файлы + соответствующим образом обрезаны (в ветке stable/current): + + + + src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml + + + + src/release/doc/en_US.ISO8859-1/errata/article.sgml + + + + Утилита sysinstall должна быть + обновлена и указывать количество доступных портов и объём дискового + пространства, требуемого для Колллекции Портов. На данный момент эта + информация хранится в файле + src/release/sysinstall/dist.c. + + После построения релиза для оповещения мирового сообщества о + выпусек релиза необходимо обновить некоторые файлы. + + + + www/share/sgml/includes.release.sgml + + + + www/share/sgml/includes.release.xsl + + + + www/en/releases/* + + + + www/en/releng/index.sgml + + + + www/en/news/news.xml + + + + src/share/misc/bsd-family-tree + + + + + + Создание тэгов релиза + + При готовности окончательного релиза следующая команда создаст + тэг RELENG_4_8_0_RELEASE. + + /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src + + Менеджеры документации и портов отвечают за внесение тэга в + соответствующие ветки с тэгом + RELEASE_4_8_0. + + Иногда в последний момент, уже после + создания последних тэгов может потребоваться внесение исправлений. + На практике это не является проблемой, так как CVS + позволяет выполнять манипуляции с тэгами по команде cvs + tag -d tagname filename. Очень + важно, чтобы все последние изменения были помечены соответствующим + тэгом, как часть релиза. Релизы FreeBSD должны быть всегда + повторяемыми. Локальные изменения в параметры окружения выпускающего + релиз недопустимы. + + + + + + + Построение релизов + + Релизы FreeBSD могут быть построены любым человеком, + имеющим быстродействующую машину и доступ к хранилищу исходных текстов. + (Это должен быть любой, так как мы предоставляем анонимный доступ к CVS! + Обратитесь к Руководству для прояснения деталей.) + Единственнным особым требованием является наличие + устройства &man.vn.4;. (В -CURRENT это устройство было заменено на + новый драйвер дисков в памяти &man.md.4;.) Если устройтво в вашем ядре + не подгружено, то модуль ядра должен быть подгружен автоматически при + выполнении команды &man.vnconfig.8; на этапе создания носителя для + загрузки. Все инструменты, необходимые для построения релиза, доступны + из хранилища CVS в каталоге src/release. Эти + инструменты предоставляют единый метод построения релизов FreeBSD. + Полный релиз может быть реально построен при помощи лишь одной команды, + включая создание ISO-образов, подходящих для записи на + CDROM, установочных дискет и установочного каталога FTP. Эта команда + называется соответствующим образом, make + release. + + + <command>make release</command> + + Для успешного построения релиза вы должны сначала заполнить каталог + /usr/obj, запустив команду make + world или просто make buildworld. Цель, + выполняемая для построения релиза, требует корректного задания + нескольких переменных, используемых при его сборке: + + + + CHROOTDIR - Каталог, используемый в среде с + изменённой корневой файловой системой при построении полного + релиза. + + + + BUILDNAME - Наименование строящегося + релиза. + + + + CVSROOT - Местонахождение + CVS-хранилища. + + + + RELEASETAG - Тэг CVS, соответствующий + релизу, который вы собираетесь строить. + + + + Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете + зеркалировать одно из них при помощи + CVSup. Поставляемый sup-файл, + /usr/share/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. + + + + Для получения более полной информации об инфраструктуре построения + релизов, пожалуйста, обратитесь к справочной странице + по &man.release.7;. + + + + Построение <application>&xfree86;</application> + + &xfree86; является важным компонентом + для многих пользователей настольных систем. До выхода FreeBSD + 4.6-RELEASE в релизах по умолчанию использовалась &xfree86; + 3.X. Самым простым способом построения этих + версий является использование скрипта + src/release/scripts/X11/build_x.sh. Он требует, + чтобы на хост, выполняющий построение, уже были установлены &xfree86; и + Tcl/Tk. После компиляции необходимых X-серверов, скрипт преобразует + все файлы в архивные, которые &man.sysinstall.8; ожидает найти в + каталоге XF86336 на установочном носителе. + + Начиная с FreeBSD 4.6-RELEASE, &man.sysinstall.8; по умолчанию + устанавливает &xfree86; 4.X, как набор + обычных пакаджей. Это могут быть как пакаджи, созданные + в процессе работы кластера построения портов, так и пакаджи, + построенные из соответствующим образом помеченного дерева + портов. + + + Важно, чтобы из файла /etc/make.conf были + удалены все установки, специфичные для конкретного хоста. К примеру, + будет глупо распространять бинарные файлы, построенные на системе с + переменной CPUTYPE, указывающей на определённый + тип процессора. + + + + + Программное обеспечение третьих лиц (<quote>ports</quote>) + + Коллекция портов + FreeBSD содержит более &os.numports; программных пакетов + сторонних разработчиков, которые доступны для FreeBSD. За поддержку + целостности дерева портов, которое может использоваться для создания + бинарных пакаджей, поставляемых с официальными релизами FreeBSD, + отвечает &a.portmgr;. + + Рассмотрение работ с нашей коллекцией пакетов сторонних + разработчиков при подготовке релизов выходит за рамки этого + документа. Этот вопрос глубоко рассмотрен в отдельной + статье, &art.re.pkgs;. + + + + ISO с релизами + + Начиная с FreeBSD 4.4, Проект FreeBSD принял решение распространять + все четыре образа ISO, ранее продаваемые через + BSDi/Wind River Systems/FreeBSD Mall как + официальные дистрибутивы на CDROM. Каждый из четырёх + дисков должен содержать файл README.TXT, + описывающий содержимое диска, файл CDROM.INF, в + котором находятся мета-данные о диске для того, чтобы + &man.sysinstall.8; мог проверять и использовать содержимое, а также + файл filename.txt, содержащий перечень содержимого + на диске. Этот перечень может быть создан простой + командой: + + /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt + + Специфичные требования для каждого CD описываются ниже. + + + Диск 1 + + Первый диск практически полностью создаётся командой + make release. Единственным изменением, которое + нужно внести в каталог disc1, является + добавление подкаталогов tools и &xfree86;, а также перенос максимально + возможного количества программных пакетов сторонних разработчиков, + которые поместятся на диск. Каталог tools + содержит программное обеспечение, позволяющее пользователям создавать + установочные дискеты из других операционных систем. Этот диск нужно + сделать загрузочным, чтобы пользователям современных ПК не нужно было + создавать установочные дискеты. + + Если предоставляется другая версия &xfree86;, до должны быть + обновлены утилита &man.sysinstall.8;, отражающая новое + местоположение, и инструкции по установке. Соответствующий код + находится в каталоге src/release/sysinstall в + ветке -STABLE или в src/usr.sbin/sysinstall в + ветке -CURRENT. Должны быть обновлены конкретно файлы + dist.c, menus.c и + config.c. + + + + Диск 2 + + Второй диск также в основном создаётся по команде make + release. Он содержит живую файловую + систему, которую можно использовать из &man.sysinstall.8; для + исправления процесса установки FreeBSD. Этот диск должен быть + загрузочным и содержать также упакованную копию хранилища CVS в + каталоге CVSROOT и демонстрационные версии + коммерческого программного обеспечения в каталоге + commerce. + + + + Диски 3 и 4 + + Оставшиеся два диска содержат дополнительные программные пакеты + для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы + отдельный пакет и все его зависимости находились + на одном и том же диске. Дополнительная информация о создании этих + дисков находится в статье &art.re.pkgs;. + + + + + + + Распространение + + + Серверы 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-го уровня появится новое программное обеспечение, в зависимотси от + того, в тоже самое ли время пакадж был загружен. Обязательно, чтобы + выпускающие релиз координировали свои действия с &a.mirror-announce; + до того, как объявлять об общедоступности нового программного + обеспечения с серверов FTP. В идеальном случае набора пакаджей к + релизу должне быть загружен по крайней мере за четыре дня до момента + выпуска релиза. Релиз должне быть загружен в промежутке от 24 до 48 + часов до момента выхода запланированного релиза с выключенными + полномочиями other. Это позволит зеркалирующим серверам + сгрузить его, но никто не сможет получить его с зеркальных серверов. + В момент выхода релиза должно быть послано сообщение в адрес + &a.mirror-announce;, говорящее о том, что релиз выпущен и наступило + время для открытия доступа на зеркальных серверах. Обязательно + вместе со временем укажите и часовой пояс, например, относительно + GMT. + + + + Тиражирование CD-ROM + + Вскоре появится: Советы по передаче ISO-образов FreeBSD на + тиражирование и применяемые меры по контролю качества. + + + + + + Расширяемость + + Хотя FreeBSD представляет собой законченную операционную систему, + ничего не заставляет вас использовать систему только в том виде, который + приготовлен нами для распространения. Мы попытались спроектировать + систему максимально расширяемой, чтобы она могла выполнять роль + платформы, на основе которой можно строить другие коммерческие продукты. + Единственным правилом, которое мы налагаем, является + настоятельная рекомендация документировать улучшения, вносимые вами в + дистрибутив FreeBSD с нетривиальными изменениями! Сообщество FreeBSD + может помогать только пользователям того программного обеспечения, + которое распространяем мы. Мы определённо приветствуем улучшения в + форме, например, инструментов установки и администрирования, но не можем + отвечать на вопросы о них. + + + Создание модифицированных загрузочных дискет + + Во многих местах имеются сложные условия, которые требуют + размещения дополнительных модулей ядра или пользовательских + инструментов на установочные дискеты. Быстрым и + неаккуратным способом сделать это является изменение + промежуточного каталога в существующей иерархии при выполнении + make release: + + + + Примените патчи или добавьте дополнительные файлы в каталог + построения релиза с изменённых корнем файловой системы. + + + + rm + ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] + + + + перестройте &man.sysinstall.8;, ядро и остальные части системы, + которые коснулись ваши изменения. + + + + chroot ${CHROOTDIR} ./mk floppies + + + + Дискеты нового релиза будут находиться в + ${CHROOTDIR}/R/stage/floppies. + + Либо может быть вызвана цель + boot.flp построения или скрипт создания файловой + системы, src/release/scripts/doFS.sh, которые + может быть вызван напрямую. + + Локальные патчи могут быть также приложены к построению релиза при + помощи задания переменной LOCAL_PATCH при выполнении + make release. + + + + Скрипты <command>sysinstall</command> + + Инструмент установки и настройки системы FreeBSD, + &man.sysinstall.8;, может работать по сценарию, полезному для + автоматизированной установке в больших компаниях. Эта функциональность + может использоваться совместно с технологией &intel; PXE[13] для + первоначальной установки систем из сети, или с модифицированными + загрузочными дискетами со скриптами sysinstall. Пример скрипта для + sysinstall доступен в дереве CVS в виде файла + src/release/sysinstall/install.cfg. + + + + + + Уроки, извлечённые из FreeBSD 4.4 + + Формально процесс подготовки релиза для 4.4 начался 1 августа 2001 + года. После этой даты все без исключения изменения в ветке + RELENG_4 FreeBSD подтверждались &a.re;. Первый + предварительный релиз для архитектуры x86 был выпущен 16 августа, за + ним выходило ещё 4 предварительных релиза, и всё закончилось 18 августа + выпуском окончательного релиза. Руководитель службы безопасности очень + плотно занимался процессом выпуска в последнюю неделю, так как в + предыдущих предварительных релизах были найдены проблемы, касающиеся + информационной безопасности. Чуть более чем за месяц в адрес &a.re; + поступило более 500 писем. + + Сообщество наших пользователей весьма чётко показало, что + безопасность и стабильность релиза FreeBSD не должна приноситься в жертву + любым назначенным срокам окончания работ или планируемым датам выхода + релиза. Проект FreeBSD за время своего существования значительно вырос, + и никогда ранее необходимость в стандартизации процедур подготовки + релизов не стояла так остро. Это стало ещё более важно, когда FreeBSD + была перенесена на новые аппаратные платформы. + + + + + Направления будущих работ + + Нашим работам по подготовке релизов жизненно важно расти вместе с + увеличением количества пользователей системы. Вместе с этим мы очень + плотно работаем над документированием действий, выполняемых при выпуске + релизов. + + + + Параллелизм - некоторые этапы построения + релиза на самом деле выполнять параллельно + затруднительно. Большинство выполняемых задач весьма + интенсивно работают с I/O, так что для ускорения процесса + make release наличие нескольких высокоскоростных + дисков гораздо более важно, чем использование нескольких процессоров. + Если для различных иерархий в &man.chroot.2;-окружении используется + несколько дисков, то извлечение из CVS деревьев + ports и doc может + выполняться одновременно с командой make world на + другом диске. Использование RAID-решений + (аппаратных или программных) может значительно сократить общее время + построения. + + + + Кроссплатформенное построение + релизов - Построить релиз для IA-64 или Alpha на + x86-оборудовании? make TARGET=ia64 release. + + + + Тестирование - Нам нужна улучшенная + автоматизированная система тестирования корректности для + FreeBSD. + + + + Инструменты установки - Наша программа + установки давно пережила свой век. В разработке находятся несколько + проектов, которые должны дать улучшенную технологию установки. Одним + из самых многообещающих из них является проект libh[5], целью + которого является создание новой интеллектуальной технологии работы с + пакаджами и программы установки с GUI. + + + + + + + Благодарности + + Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он + дал мне возможность взять под свою ответственность некоторые части + процесса подготовки релиза FreeBSD 4.4, а также за все годы его работы, + сделавшие FreeBSD такой, какой она является сейчас. Конечно, релиз не + был бы возможен без той работы, которую проделали &a.asami;, &a.steve;, + &a.bmah;, &a.nik;, &a.obrien;, &a.kris;, &a.jhb; и остальные члены + сообщества разработчиков FreeBSD. Я также рад выразить благодарность + &a.rgrimes; и &a.phk;, а также остальным, работавшим над инструментами + подготовки релизов в первые годы существования FreeBSD. Эта статья была + также написана под впечатлением документации по подготовке релизов от + CSRG[14], NetBSD Project[11] и замечаний Джона Балдвина (John Baldwin) + по предлагаемому процессу подготовки релизов[12]. + + + + + Справочная литература + + [1] CVS - Concurrent Versions System + + + [2] CVSup - The CVS-Optimized General Purpose Network File + Distribution System + + [3] + + [4] Коллекция портов FreeBSD + + + [5] Проект libh + + + [6] Коммиттеры FreeBSD + + + [7] Правление FreeBSD + + + [8] Руководство FreeBSD + + + [9] GNATS: The GNU Bug Tracking System + + + [10] Статистика FreeBSD PR + + + [11] NetBSD Developer Documentation: Release Engineering + + [12] John Baldwin's FreeBSD Release Engineering Proposal + + [13] PXE Jumpstart Guide + + + [14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: + + The Release Engineering of 4.3BSD + +