diff options
Diffstat (limited to 'documentation/content/ru/articles/releng/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/releng/_index.adoc | 357 |
1 files changed, 154 insertions, 203 deletions
diff --git a/documentation/content/ru/articles/releng/_index.adoc b/documentation/content/ru/articles/releng/_index.adoc index 5b539f65dc..055890b07c 100644 --- a/documentation/content/ru/articles/releng/_index.adoc +++ b/documentation/content/ru/articles/releng/_index.adoc @@ -1,10 +1,13 @@ --- -title: Подготовка релизов FreeBSD authors: - - author: Murray Stokely + - + author: 'Murray Stokely' email: murray@FreeBSD.org webpage: https://people.FreeBSD.org/~murray/ -trademarks: ["freebsd", "cvsup", "intel", "general"] +description: 'В этом документе описывается подход, ранее использовавшийся командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества' +tags: ["Release", "Engineering", "Historical", "FreeBSD"] +title: 'Устаревшая разработка релизов FreeBSD' +trademarks: ["freebsd", "intel", "general"] --- = Подготовка релизов FreeBSD @@ -41,7 +44,12 @@ endif::[] [.abstract-title] Аннотация -В этой статье описывается подход, который используется группой подготовки релизов FreeBSD для создания качественных версий Операционной Системы FreeBSD. В ней детально описывается методология, используемая для официальных релизов FreeBSD и рассказывается об инструментах, доступных тем, кто интересуется созданием модифицированных релизов FreeBSD для тиражирования внутри организации или в коммерческих целях. +[NOTE] +==== +Этот документ устарел и не точно описывает текущие процедуры выпуска релизов команды FreeBSD Release Engineering. Он сохранен в исторических целях. Текущие процедуры, используемые командой FreeBSD Release Engineering, доступны в статье extref:{freebsd-releng}[FreeBSD Release Engineering]. +==== + +В этом документе описывается подход, используемый командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества. Подробно излагается методология, применяемая для официальных выпусков FreeBSD, а также описываются инструменты, доступные тем, кто заинтересован в создании собственных релизов FreeBSD для корпоративного внедрения или использования в коммерческой деятельности. ''' @@ -50,112 +58,128 @@ toc::[] [[introduction]] == Введение -Разработка FreeBSD представляет собой весьма открытый процесс. FreeBSD составляется в результате общих усилий тысяч людей по всему миру. Проект FreeBSD предоставляет анонимный публичный доступ по протоколу CVS[1], так что любой может получить доступ к журналу изменений, разницам (патчам) между ветками разработки и другим продвинутым возможностям, которые даёт строгое управление исходным кодом. Это сильно помогает в привлечении к FreeBSD всё большего количества талантливых разработчиков. Однако, и я думаю, что все со мной согласятся, наступит хаос, если доступ по записи будет открыт всем в Internet. Поэтому только "избранная" группа примерно из 300 человек имеет доступ по записи в CVS-хранилище. Эти _коммиттеры[5]_ отвечают в целом за разработку FreeBSD. Выбираемая из самых заслуженных разработчиков _группа правления[6]_ обеспечивает некоторый уровень управления проектом. +Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion footnote:[Subversion, http://subversion.apache.org] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право записи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти extref:{contributors}[коммиттеры FreeBSD, staff-committers]footnote:[extref:{contributors}[коммиттеры FreeBSD, staff-committers]] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Избранная группа разработчиков — link:https://www.FreeBSD.org/administration/#t-core[Core Team]footnote:[link:https://www.FreeBSD.org/administration/#t-core[Core Team FreeBSD]] — обеспечивает некоторый уровень руководства проектом. + +Быстрый темп разработки `FreeBSD` делает основную ветку разработки непригодной для повседневного использования широкой публикой. В частности, требуются усилия по стабилизации для доведения системы разработки до релиза производственного качества. Для решения этого конфликта разработка продолжается по нескольким параллельным направлениям. Основная ветка разработки — это _HEAD_ или _trunk_ нашего дерева Subversion, известная как "FreeBSD-CURRENT" или сокращённо "-CURRENT". + +Набор более стабильных ветвей поддерживается под названием "FreeBSD-STABLE" или сокращённо "-STABLE". Все ветви находятся в главном хранилище Subversion, которое поддерживается проектом FreeBSD. FreeBSD-CURRENT — это "передний край" разработки FreeBSD, куда сначала попадают все новые изменения. FreeBSD-STABLE — это ветвь разработки, на основе которой выпускаются основные релизы. Изменения попадают в эту ветвь с другой скоростью и с общим предположением, что они сначала попали в FreeBSD-CURRENT и были тщательно протестированы сообществом пользователей. -Темп разработок, ведущихся во `FreeBSD`, оставляет мало времени на тщательную доводку системы до качества продуктивного релиза. Для решения этой проблемы разработка ведётся в два параллельных потока. Основной веткой разработки является __HEAD__, она же _основная линия_ нашего дерева CVS, известная также под именем "FreeBSD-CURRENT" или, для краткости, "-CURRENT". +Термин _stable_ в названии ветки относится к предполагаемой стабильности бинарного интерфейса приложений (ABI), которую гарантирует проект. Это означает, что пользовательское приложение, скомпилированное на более старой версии системы из той же ветки, будет работать на более новой системе из той же ветки. Стабильность ABI значительно улучшилась по сравнению с предыдущими выпусками. В большинстве случаев бинарные файлы со старых систем _STABLE_ работают без изменений на более новых системах, включая __HEAD__, при условии, что не используются интерфейсы управления системой. -Поддерживается и более стабильная ветка, известная как "FreeBSD-STABLE" или, для краткости, "-STABLE". Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются при помощи CVSup[2] на зеркала по всему миру. FreeBSD-CURRENT[7] является "передним краем" работ над FreeBSD, через который попадают все изменения в системе. FreeBSD-STABLE является веткой разработки, из которой создаются основные релизы. В эту ветку изменения попадают разными путями, и предполагается, что сначала они попали в FreeBSD-CURRENT, где были тщательно протестированы сообществом наших пользователей. +В промежуточный период между выпусками еженедельные снимки состояния системы автоматически создаются сборщиками FreeBSD Project и доступны для загрузки по адресу `https:/download.FreeBSD.org/snapshots/`. Широкое распространение бинарных снимков выпусков, а также склонность нашего сообщества пользователей следить за разработкой -STABLE с помощью Subversion и команды "`make buildworld`" footnote:[extref:{handbook}[Пересборка world, makeworld]] помогает поддерживать FreeBSD-STABLE в очень надежном состоянии даже до того, как активизируются мероприятия по обеспечению качества перед основным выпуском. -В промежутке между релизами машинами Проекта FreeBSD, выделенными для построения системы, ежемесячно автоматически собираются снэпшоты, которые доступны для закачки по адресу `ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/`. Общедоступность снэпшотов бинарных релизов, а также желание сообщества наших пользователей отслеживать работу над -STABLE при помощи CVSup и "`make world`"[7] помогает поддержать весьма хорошее качество FreeBSD-STABLE, даже до выполнения мероприятий проверки качества, предваряющих выпуск основных релизов. +Помимо снимков установочных ISO, также предоставляются еженедельные образы виртуальных машин для использования с VirtualBox, qemu или другим популярным эмуляционным программным обеспечением. Образы виртуальных машин можно загрузить с `https://download.FreeBSD.org/snapshots/VM-IMAGES/`. -В процессе выпуска релиза пользователи постоянно присылают сообщения об ошибках и пожелания по расширению функциональности. Сообщения о проблемах попадают в нашу базу данных GNATS[8] по электронной почте, посредством утилиты man:send-pr[1] или через Web-интерфейс, доступный по адресу http://www.FreeBSD.org/send-pr/[http://www.FreeBSD.org/send-pr/]. +Образы виртуальных машин сжаты с помощью man:xz[1] и занимают примерно 150 МБ, а при подключении к виртуальной машине содержат разреженную файловую систему размером 10 ГБ. -Для удовлетворения наших самых консервативно настроенных пользователей, начиная с FreeBSD 4.3, появились ветки для отдельных релизов. Эти ветки создаются вскоре после того, как выпускается окончательный релиз. После его выхода в ветку релиза помещаются только самые критичные исправления и добавления, касающиеся безопасности. Кроме обновлений исходных текстов посредством CVS, для систем веток RELENG_``__X_Y__`` имеются и бинарные наборы патчей. +Отчеты об ошибках и запросы функций постоянно отправляются пользователями в течение цикла выпуска. Сообщения о проблемах вносятся в нашу базу данных Bugzilla через веб-интерфейс, доступный по адресу https://www.freebsd.org/support/bugreports/[https://www.freebsd.org/support/bugreports/]. -=== Что обсуждается в данном документе? +Для обслуживания наиболее консервативных пользователей, начиная с FreeBSD 4.3, были введены индивидуальные ветки релизов. Эти ветки создаются незадолго до выпуска финального релиза. После выхода релиза на ветку вносятся только самые критические исправления безопасности и дополнения. Помимо обновлений исходного кода через Subversion, доступны бинарные патч-наборы для поддержания актуальности систем на ветках _releng/X.Y_. -В последующих главах этой статьи обсуждаются: +=== Что описывает эта статья -<<release-proc>>:: -Различные этапы процесса подготовки релиза вплоть до построения актуальной системы. +Следующие разделы этой статьи описывают: -<<release-build>>:: -Процесс сборки. +crossref:releng[release-proc, Процесс выпуска релиза]:: +Различные этапы процесса разработки релиза, предшествующие непосредственной сборке системы. -<<extensibility>>:: -Как базовый релиз может быть расширен третьими сторонами. +crossref:releng[release-build, Сборка релиза]:: +Фактический процесс сборки. -<<lessons-learned>>:: -Некоторые из уроков, полученных при выпуске релиза FreeBSD 4.4. +crossref:releng[extensibility, Расширяемость]:: +Как базовый выпуск может быть расширен третьими сторонами. -<<future>>:: -Направления будущих работ. +crossref:releng[lessons-learned, Уроки, извлеченные из FreeBSD 4.4]:: +Некоторые уроки, извлеченные в процессе выпуска FreeBSD 4.4. + +crossref:releng[future, Перспективы развития]:: +Перспективные направления развития. [[release-proc]] == Процесс выпуска релиза -Новые релизы FreeBSD выпускаются из ветки -STABLE с интервалом примерно в четыре месяца. Процесс выпуска релизов FreeBSD начинается за 45 дней до предполагаемой даты релиза с того, что ответственный за релиз посылает сообщение по электронной почте в адрес списков рассылки для разработчиков, чтобы напомнить последним о наличии всего лишь 15 дней на внесение новых изменений до момента заморозки кода. В этот период многие разработчики выполняют действия, известные как "MFC-переносы". MFC означает "Merge From CURRENT" (перенос из CURRENT) и описывает процесс переноса протестированных изменений из нашего дерева разработки -CURRENT в наше дерево -STABLE. +Новые выпуски FreeBSD выходят из ветки -STABLE примерно с интервалом в четыре месяца. Процесс выпуска FreeBSD начинает набирать обороты за 70-80 дней до предполагаемой даты выпуска, когда инженер выпуска отправляет электронное письмо в списки рассылки разработчиков, напоминая им, что у них осталось всего 15 дней для интеграции новых изменений до заморозки кода. В это время многие разработчики выполняют так называемые "MFC-проверки". + +MFC означает "Merge From CURRENT" и описывает процесс переноса проверенного изменения из нашей ветки разработки -CURRENT в ветку -STABLE. Политика проекта требует, чтобы любое изменение сначала было применено к основной ветке, а затем перенесено в ветки -STABLE после достаточного внешнего тестирования пользователями -CURRENT (ожидается, что разработчики тщательно проверят изменение перед внесением в -CURRENT, но невозможно для одного человека проверить все варианты использования универсальной операционной системы). Минимальный срок для MFC составляет 3 дня, который обычно используется только для тривиальных или критических исправлений ошибок. -=== Просмотр кода +=== Проверка кода -За тридцать дней до предполагаемого релиза хранилище исходных текстов переводится в режим "стабилизации кода". В этот период все изменения в дереве -STABLE должны подтверждаться `{re}`. В первый 15-дневный период разрешены следующие типы изменений: +За шестьдесят дней до предполагаемого релиза репозиторий исходного кода переходит в режим «заморозки кода». В этот период все коммиты в ветку -STABLE должны быть одобрены `{re}`. Процесс утверждения технически обеспечивается предкоммитным хуком. В этот период допускаются следующие виды изменений: * Исправления ошибок. -* Обновление документации. -* Исправления любого характера, касающиеся безопасности. -* Незначительные исправления в драйверах устройств, такие, как, например, добавление новых ID устройств. -* Любые другие изменения, которые одобряет группа подготовки релиза, с учётом потенциального риска. +* Обновления документации. +* Исправления, связанные с безопасностью, любого рода. +* Незначительные изменения в драйверах устройств, такие как добавление новых идентификаторов устройств. +* Обновления драйверов от поставщиков. +* Любое дополнительное изменение, которое команда разработки релизов сочтет оправданным, учитывая потенциальный риск. + +Вскоре после начала заморозки кода создаётся образ _BETA1_ и выпускается для широкого тестирования. В период заморозки кода не реже чем раз в две недели выпускается как минимум один бета-образ или кандидат в релизы, пока не будет готов финальный выпуск. В дни, предшествующие финальному релизу, команда разработки выпусков постоянно взаимодействует с командой security-officer, сопровождающими документации и сопровождающими портов, чтобы убедиться, что все необходимые компоненты для успешного релиза доступны. -После первых 15 дней стабилизации кода выпускается __предварительный релиз__, предназначенный для широкого тестирования, а код переводится в состояние "заморозки", когда становится гораздо труднее доказывать необходимость внесения новых изменений в систему, если они не касаются исправления серьёзных ошибок или информационной безопасности. Во время заморозки кода каждую неделю выпускается не менее одной предварительной версии релиза, до тех пор, пока не будет готов окончательный вариант релиза. В дни, предшествующие выпуску окончательного релиза, группа его подготовки работает в постоянном контакте со службой безопасности и людьми, поддерживающими документацию и порты, чтобы обеспечить доступность всех компонентов, необходимых для успешного выпуска релиза. +После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создается ветка релиза, и образы _Release Candidate_ (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жесткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности. -=== Контрольный список для проверки окончательного релиза +=== Контрольный список финального выпуска -После того, как для широкого тестирования было выпущено несколько предварительных релизов и все основные проблемы были решены, может начаться процесс "шлифовки" окончательного релиза. +Когда несколько образов BETA станут доступны для широкого тестирования и все основные проблемы будут устранены, можно приступать к финальной "доводке" выпуска. [[rel-branch]] ==== Создание ветки релиза -Как сказано во вводной части, ветка `RELENG_X_Y` является сравнительно новым добавлением в нашей методологии подготовки релизов. Первым шагом в создании этой ветки является проверка того, что вы работаете с самой последней версией исходных текстов `RELENG_X`, из _которой_ вы хотите создать новую ветку. +[NOTE] +==== +Во всех примерах ниже `$FSVN` указывает на расположение репозитория Subversion FreeBSD, `svn+ssh://svn.FreeBSD.org/base/`. +==== + +Расположение веток FreeBSD в Subversion описано в extref:{committers-guide}[Руководстве коммиттера, subversion-primer-base-layout]. Первым шагом в создании ветки является определение ревизии исходников `stable/_X_`, от которой вы хотите сделать _ответвление_. -[source,shell] +[source, shell] .... -/usr/src# cvs update -rRELENG_4 -P -d +# svn log -v $FSVN/stable/9 .... -Следующим шагом является создание _тэга_ точки ответвления, чтобы диффы облегчили работу с началом ветки в CVS: +Следующий шаг — создание _ветки релиза_ -[source,shell] +[source, shell] .... -/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src +# svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 .... -После этого создаётся тэг новой ветки по команде: +Эту ветку можно извлечь: -[source,shell] +[source, shell] .... -/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src +# svn co $FSVN/releng/9.2 src .... [NOTE] ==== -__Использование тэгов `RELENG_*` разрешено только менеджерам CVS и участникам группы по выпуску релизов.__ +Создание ветки `releng` и тегов `release` выполняется командой link:https://www.FreeBSD.org/administration/#t-re[Release Engineering Team]. ==== -"_Тэгом_ " в понятии CVS называют метку, которая идентифицирует исходный текст в некоторый момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в будущем тот, кто строит релиз, всегда сможет воспользоваться тем же самым кодом, что использовался нами для создания официальных релизов Проекта FreeBSD. - -image::branches-head.png[Ветви разработки FreeBSD] +image::branches-head.png["Ветка разработки FreeBSD"] -image::branches-releng3.png[Ветка FreeBSD 3.x STABLE] +image::branches-releng3.png["Ветка STABLE FreeBSD 3.x"] -image::branches-releng4.png[Ветка FreeBSD 4.x STABLE] +image::branches-releng4.png["Ветка FreeBSD 4.x STABLE"] -image::branches-releng5.png[Ветка FreeBSD 5.x STABLE] +image::branches-releng5.png["Ветка STABLE FreeBSD 5.x"] -image::branches-releng6.png[Ветка FreeBSD 6.x STABLE] +image::branches-releng6.png["Ветка FreeBSD 6.x STABLE"] -image::branches-releng7.png[Ветка FreeBSD 7.x STABLE] +image::branches-releng7.png["Ветка FreeBSD 7.x STABLE"] -image::branches-releng8.png[Ветка FreeBSD 8.x STABLE] +image::branches-releng8.png["Ветка FreeBSD 8.x STABLE"] -image::branches-releng9.png[Ветка FreeBSD 9.x STABLE] +image::branches-releng9.png["Ветка FreeBSD 9.x STABLE"] [[versionbump]] ==== Увеличение номера версии -Перед тем, как окончательный релиз будет помечен, построен и выпущен, необходимо модифицировать следующие файлы, отразив в них корректную версию FreeBSD: +Перед тем как финальный выпуск может быть помечен, собран и выпущен, следующие файлы должны быть изменены, чтобы отражать корректную версию FreeBSD: -* [.filename]#doc/ru_RU.KOI8-R/books/handbook/mirrors/chapter.xml# +* [.filename]#doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml# * [.filename]#doc/en_US.ISO8859-1/books/porters-handbook/book.xml# +* [.filename]#doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi# +* [.filename]#ports/Tools/scripts/release/config# * [.filename]#doc/shared/xml/freebsd.ent# * [.filename]#src/Makefile.inc1# * [.filename]#src/UPDATING# @@ -164,154 +188,125 @@ image::branches-releng9.png[Ветка FreeBSD 9.x STABLE] * [.filename]#src/release/doc/en_US.ISO8859-1/shared/xml/release.dsl# * [.filename]#src/release/doc/shared/examples/Makefile.relnotesng# * [.filename]#src/release/doc/shared/xml/release.ent# -* [.filename]#src/shared/examples/cvsup/standard-supfile# * [.filename]#src/sys/conf/newvers.sh# * [.filename]#src/sys/sys/param.h# * [.filename]#src/usr.sbin/pkg_install/add/main.c# -* [.filename]#www/en/docs/man.xml# -* [.filename]#www/en/cgi/ports.cgi# -* [.filename]#ports/Tools/scripts/release/config# +* [.filename]#doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml# -Новый релиз должен быть также отражён в файлах замечаний к релизу и информации о замеченных ошибках (в ветке релиза), а файлы соответствующим образом обрезаны (в ветке stable/current): +Заметки о выпуске и файлы с опечатками также необходимо адаптировать для нового выпуска (в ветке выпуска) и соответствующим образом обрезать (в ветке stable/current): * [.filename]#src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml# * [.filename]#src/release/doc/en_US.ISO8859-1/errata/article.xml# -Утилита Sysinstall должна быть обновлена и указывать количество доступных портов и объём дискового пространства, требуемого для Коллекции Портов[4]. На данный момент эта информация хранится в файле [.filename]#src/usr.sbin/sysinstall/dist.c#. - -После построения релиза для оповещения мирового сообщества о выпуске релиза необходимо обновить некоторые файлы. +В Sysinstall следует добавить информацию о количестве доступных портов и объеме дискового пространства, необходимого для коллекции портов. footnote:[Коллекция портов FreeBSD https://ports.FreeBSD.org] В настоящее время эта информация хранится в [.filename]#src/usr.sbin/bsdinstall/dist.c#. -* [.filename]#doc/shared/images/articles/releng/branches-relengX.pic# -* [.filename]#www/shared/xml/advisories.xml# -* [.filename]#www/shared/xml/includes.release.xml# -* [.filename]#www/shared/xml/includes.release.xsl# -* [.filename]#www/en/releases/*# -* [.filename]#www/en/releng/index.xml# -* [.filename]#www/en/news/news.xml# -* [.filename]#www/en/search/web.atoz# -* [.filename]#src/shared/misc/bsd-family-tree# +После сборки выпуска следует обновить ряд файлов, чтобы объявить о выпуске. Эти файлы находятся относительно `head/` в поддереве `doc/` Subversion. -[[versionbump-major]] -==== Подготовка новой старшей релиз ветки (RELENG_X) +* [.filename]#share/images/articles/releng/branches-relengX.pic# +* [.filename]#head/shared/xml/release.ent# +* [.filename]#en_US.ISO8859-1/htdocs/releases/*# +* [.filename]#en_US.ISO8859-1/htdocs/releng/index.xml# +* [.filename]#share/xml/news.xml# -Когда новая старшая релиз ветка, такая как `RELENG_6` ответвляется из HEAD, некоторые дополнительные файлы должны быть обновлены перед тем, как релизы будут созданы из этой новой ветки. +Кроме того, обновите файл "Генеалогическое древо BSD": -* [.filename]#src/shared/examples/cvsup/stable-supfile# - когда применимо, должен быть обновлен, чтобы указывать на новую -STABLE ветку. +* [.filename]#src/shared/misc/bsd-family-tree# -==== Создание тэгов релиза +==== Создание тега релиза -При готовности окончательного релиза следующая команда создаст тэг `RELENG_4_8_0_RELEASE`. +Когда финальный выпуск будет готов, следующая команда создаст тег `release/9.2.0`. -[source,shell] +[source, shell] .... -/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src +# svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0 .... -Менеджеры документации и портов отвечают за внесение тэга в соответствующие ветки с тэгом `RELEASE_4_8_0`. +Менеджеры документации и портов ответственны за добавление тега `tags/RELEASE_9_2_0` в соответствующие деревья. -Иногда в последний момент, уже _после_ создания последних тэгов может потребоваться внесение исправлений. На практике это не является проблемой, так как CVS позволяет выполнять манипуляции с тэгами по команде `cvs tag -d _tagname filename_`. Очень важно, чтобы все последние изменения были помечены соответствующим тэгом, как часть релиза. Релизы FreeBSD должны быть всегда повторяемыми. Локальные изменения в параметры окружения выпускающего релиз недопустимы. +Когда команда Subversion `svn cp` используется для создания __тега релиза (release tag)__, это идентифицирует исходный код на определённый момент времени. Создавая теги, мы гарантируем, что будущие сборщики релизов всегда смогут использовать тот же исходный код, который использовался для создания официальных релизов проекта FreeBSD. [[release-build]] -== Построение релизов - -"Релизы" FreeBSD могут быть построены любым человеком, имеющим быстродействующую машину и доступ к хранилищу исходных текстов. (Это должен быть любой, так как мы предоставляем анонимный доступ к CVS! Обратитесь к Руководству для прояснения деталей.) _Единственным_ особым требованием является наличие устройства man:md[4]. Если устройство в вашем ядре не подгружено, то модуль ядра должен быть подгружен автоматически при выполнении команды man:mdconfig[8] на этапе создания носителя для загрузки. Все инструменты, необходимые для построения релиза, доступны из хранилища CVS в каталоге [.filename]#src/release#. Эти инструменты предоставляют единый метод построения релизов FreeBSD. Полный релиз может быть реально построен при помощи лишь одной команды, включая создание ISO-образов, подходящих для записи на CDROM, установочных дискет и установочного каталога FTP. Эта команда называется соответствующим образом: `make release`. +== Сборка релиза -=== `make release` +Сборка "релизов" FreeBSD может быть выполнена любым пользователем, имеющим быстрый компьютер и доступ к репозиторию исходного кода. (Это должно быть доступно каждому, так как мы предоставляем доступ через Subversion! Подробности см. в extref:{handbook}[разделе Subversion в Руководстве, svn].) _Единственное_ специальное требование — доступность устройства man:md[4]. Если устройство не загружено в ваше ядро, то модуль ядра должен автоматически загрузиться при выполнении man:mdconfig[8] во время этапа создания загрузочного носителя. Все необходимые инструменты для сборки релиза доступны в репозитории Subversion в [.filename]#src/release#. Эти инструменты предназначены для обеспечения единообразного способа сборки релизов FreeBSD. Полный релиз может быть собран всего одной командой, включая создание ISO-образов, пригодных для записи на CDROM или DVD, а также каталога для установки по FTP. man:release[7] полностью документирует скрипт `src/release/generate-release.sh`, который используется для сборки релиза. `generate-release.sh` является обёрткой для цели Makefile: `make release`. -Для успешного построения релиза вы должны сначала заполнить каталог [.filename]#/usr/obj#, запустив команду `make world` или просто `make buildworld`. Цель, выполняемая для построения релиза, требует корректного задания нескольких переменных, используемых при его сборке: +=== Сборка релиза -* `CHROOTDIR` - Каталог, используемый в среде с изменённой корневой файловой системой при построении полного релиза. -* `BUILDNAME` - Наименование строящегося релиза. -* `CVSROOT` - Местонахождение CVS-хранилища. -* `RELEASETAG` - Тэг CVS, соответствующий релизу, который вы собираетесь строить. +man:release[7] документирует точные команды, необходимые для сборки релиза FreeBSD. Следующая последовательность команд может собрать релиз 9.2.0: -Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете зеркалировать одно из них при помощи extref:{handbook}[CVSup, svn]. Поставляемый sup-файл, [.filename]#/usr/shared/examples/cvsup/cvs-supfile#, может служить хорошей отправной точкой для зеркалирования хранилища CVS. +[source, shell] +.... +# cd /usr/src/release +# sh generate-release.sh release/9.2.0 /local3/release +.... -Если `RELEASETAG` опущен, то релиз будет строиться из ветки `HEAD` (известной как -CURRENT). Релизы, строящиеся из этой ветки обычно называют "снэпшотами -CURRENT". +После выполнения этих команд все подготовленные файлы релиза будут доступны в каталоге [.filename]#/local3/release/R#. -Для настройки построения релиза существует много других переменных Большинство из этих переменных описаны в начале файла [.filename]#src/release/Makefile#. Точная команда, служащая для построения официального релиза FreeBSD 4.7 (x86) такова: +Файл [.filename]#Makefile# для выпуска можно разбить на несколько отдельных этапов. -[source,shell] -.... -make release CHROOTDIR=/local3/release \ - BUILDNAME=4.7-RELEASE \ - CVSROOT=/host/cvs/usr/home/ncvs \ - RELEASETAG=RELENG_4_7_0_RELEASE -.... +* Создание изолированного окружения системы в отдельной иерархии каталогов с помощью "`make installworld`". +* Извлечение из Subversion чистой версии исходного кода системы, документации и портов в иерархию сборки релиза. +* Заполнение каталогов [.filename]#/etc# и [.filename]#/dev# в chroot-окружении. +* Изменение корневой директории на верхний каталог иерархии сборки релиза с помощью `chroot`, чтобы усложнить влияние внешней среды на эту сборку. +* Запуск `make world` в окружении `chroot`. +* Сборка связанных с Kerberos бинарных файлов. +* Сборка ядра [.filename]#GENERIC#. +* Создание промежуточной структуры каталогов, в которой будут собираться и упаковываться бинарные дистрибутивы. +* Сборка и установка инструментария для документации, необходимого для преобразования исходников документации (SGML) в HTML и текстовые документы, которые будут поставляться с релизом. +* Сборка и установка непосредственно документации (руководства пользователя, учебные пособия, примечания к выпуску, списки совместимого оборудования и так далее). +* Создание распространяемых tar-архивов с бинарными файлами и исходными кодами. +* Создание иерархии установки FTP. +* _(необязательно)_ Создание ISO-образов для носителей CDROM/DVD. -[.filename]#Makefile# для релиза может быть разбит на несколько различных шагов. - -* Создание чистого системного окружения в отдельной иерархии каталогов по команде "`make installworld`". -* Выгрузка из CVS чистой версии исходных текстов системы, документации и портов в иерархию для построения релиза. -* Создание копии [.filename]#/etc# и [.filename]#/dev# в окружении с изменённым корнем файловой системы. -* Смена корневой файловой системы на иерархию построения релиза, чтобы избежать влияния внешнего окружения на построение. -* Выполнение `make world` в окружении с изменённой корневой файловой системой. -* Построение бинарных файлов для работы с Kerberos. -* Построение ядра [.filename]#GENERIC#. -* Создание промежуточного дерева каталогов, где будут строиться бинарные файлы и формироваться дистрибутивы. -* Построение и установка инструментов для работы с документацией, необходимых для преобразования исходных текстов документации (SGML) в формат HTML и текстовые документы, которые сопутствуют релиз. -* Построение и установка актуальной документации (руководства пользователей, учебники, замечания к релизу, перечень аппаратной совместимости и так далее.) -* Построение "свёрнутых" бинарных файлов, используемых на установочных дискетах. -* Подготовка дистрибутивных архивов бинарных файлов и исходных текстов. -* Создание загрузочного носителя и "fixit"-дискеты. -* Создание иерархии для установки при помощи FTP. -* _(опционально)_ Создание образов ISO для носителей CDROM/DVD. - -Для получения более полной информации об инфраструктуре построения релизов, пожалуйста, обратитесь к справочной странице по man:release[7]. +Для получения дополнительной информации о инфраструктуре сборки релизов, обратитесь к man:release[7]. [NOTE] ==== -Важно, чтобы из файла [.filename]#/etc/make.conf# были удалены все установки, специфичные для конкретного хоста. К примеру, будет глупо распространять бинарные файлы, построенные на системе с переменной `CPUTYPE`, указывающей на определённый тип процессора. +Важно удалить все специфичные для сайта настройки из [.filename]#/etc/make.conf#. Например, было бы неразумно распространять бинарные файлы, собранные на системе с установленным `CPUTYPE` для конкретного процессора. ==== -=== Программное обеспечение третьих лиц ("ports") +=== Предоставленное программное обеспечение ("порты") -http://www.FreeBSD.org/ports[Коллекция портов FreeBSD] содержит более {numports} программных пакетов сторонних разработчиков, которые доступны для FreeBSD. За поддержку целостности дерева портов, которое может использоваться для создания бинарных пакетов, поставляемых с официальными релизами FreeBSD, отвечает `{portmgr}`. +https://ports.FreeBSD.org[Коллекция портов FreeBSD] представляет собой набор из более чем {numports} сторонних программных пакетов, доступных для FreeBSD. `{portmgr}` отвечает за поддержание согласованного дерева портов, которое может быть использовано для создания бинарных пакетов, поставляемых с официальными выпусками FreeBSD. -Рассмотрение работ с нашей коллекцией пакетов сторонних разработчиков при подготовке релизов выходит за рамки этого документа. Этот вопрос глубоко рассмотрен в отдельной статье, link:{releng-packages}[The Release Engineering of Third Party Packages]. +=== Релизные ISO-образы -=== ISO с релизами +Начиная с FreeBSD 4.4, проект FreeBSD решил выпустить все четыре образа ISO, которые ранее продавались на «официальных» дистрибутивах CDROM от _BSDi/Wind River Systems/FreeBSD Mall_. Каждый из четырёх дисков должен содержать файл [.filename]#README.TXT#, объясняющий содержимое диска, файл [.filename]#CDROM.INF#, предоставляющий метаданные для диска, чтобы man:bsdinstall[8] мог проверить и использовать содержимое, и файл [.filename]#filename.txt#, содержащий манифест диска. Этот _манифест_ можно создать простой командой: -Начиная с FreeBSD 4.4, Проект FreeBSD принял решение распространять все четыре образа ISO, ранее продаваемые через _BSDi/Wind River Systems/FreeBSD Mall_ как "официальные" дистрибутивы на CDROM. Каждый из четырёх дисков должен содержать файл [.filename]#README.TXT#, описывающий содержимое диска, файл [.filename]#CDROM.INF#, в котором находятся мета-данные о диске для того, чтобы man:sysinstall[8] мог проверять и использовать содержимое, а также файл [.filename]#filename.txt#, содержащий перечень содержимого на диске. Этот _перечень_ может быть создан простой командой: - -[source,shell] +[source, shell] .... /stage/cdrom# find . -type f | sed -e 's/^\.\///' | sort > filename.txt .... -Специфичные требования для каждого CD описываются ниже. +Конкретные требования для каждого CD приведены ниже. ==== Диск 1 -Первый диск практически полностью создаётся командой `make release`. Единственным изменением, которое нужно внести в каталог [.filename]#disc1#, является добавление подкаталога [.filename]#tools#, а также перенос максимально возможного количества программных пакетов сторонних разработчиков, которые поместятся на диск. Каталог [.filename]#tools# содержит программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск нужно сделать загрузочным, чтобы пользователям современных ПК не нужно было создавать установочные дискеты. +Первый диск почти полностью создаётся командой `make release`. Единственные изменения, которые следует внести в каталог [.filename]#disc1#, — это добавление директории [.filename]#tools# и как можно большего количества популярных сторонних программных пакетов, которые поместятся на диск. В каталоге [.filename]#tools# содержится программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск должен быть загрузочным, чтобы пользователям современных ПК не требовалось создавать установочные дискеты. -Если в релиз необходимо включить специализированное ядро, то необходимо модифицировать man:sysinstall[8] и man:release[7], добавив в них инструкции по установке. Соответствующий код находится в [.filename]#src/release# и [.filename]#src/usr.sbin/sysinstall#. В частности, в [.filename]#src/usr.sbin/sysinstall# необходимо будет редактировать [.filename]#src/release/Makefile#, [.filename]#dist.c#, [.filename]#dist.h#, [.filename]#menus.c#, [.filename]#install.c# и [.filename]#Makefile#. Также может потребоваться обновить [.filename]#sysinstall.8#. +Если требуется включить пользовательское ядро FreeBSD, необходимо обновить man:bsdinstall[8] и man:release[7], чтобы включить инструкции по установке. Соответствующий код содержится в [.filename]#src/release# и [.filename]#src/usr.sbin/bsdinstall#. В частности, потребуется обновить файл [.filename]#src/release/Makefile#, а также [.filename]#dist.c#, [.filename]#dist.h#, [.filename]#menus.c#, [.filename]#install.c# и [.filename]#Makefile# в каталоге [.filename]#src/usr.sbin/bsdinstall#. При желании можно также обновить [.filename]#bsdinstall.8#. ==== Диск 2 -Второй диск также в основном создаётся по команде `make release`. Он содержит "живую файловую систему", которую можно использовать из man:sysinstall[8] для исправления процесса установки FreeBSD. Этот диск должен быть загрузочным и содержать также упакованную копию хранилища CVS в каталоге [.filename]#CVSROOT# и демонстрационные версии коммерческого программного обеспечения в каталоге [.filename]#commerce#. - -==== Диски 3 и 4 - -Оставшиеся два диска содержат дополнительные программные пакеты для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы отдельный пакет и все его _зависимости_ находились на одном и том же диске. Дополнительная информация о создании этих дисков находится в статье link:{releng-package}[The Release Engineering of Third Party Packages]. +Второй диск также в основном создаётся командой `make release`. Этот диск содержит «живую файловую систему», которая может использоваться через man:bsdinstall[8] для диагностики установки FreeBSD. Этот диск должен быть загрузочным и также содержать сжатую копию репозитория CVS в директории [.filename]#CVSROOT# и демонстрационные версии коммерческого ПО в директории [.filename]#commerce#. -==== Поддержка нескольких дисков +==== Поддержка нескольких томов -Sysinstall поддерживает установку пакетов с нескольких дисков. Для это нужно, чтобы на каждом диске был файл [.filename]#INDEX#, содержащий названия всех пакетов со всех дисков, с дополнительным полем, указывающем на каком диске содержится данный конкретный пакет. Также, на каждом диске, в файле [.filename]#cdrom.inf# должна быть указана переменная `CD_VOLUME` для того, чтобы sysinstall мог определить какой этой диск. Когда пользователь будет пытаться установить пакет, которого нет на текущем диске, sysinstall выдаст запрос на вставку соответствующего диска. +Sysinstall поддерживает установку пакетов с нескольких томов. Для этого каждый диск должен содержать файл [.filename]#INDEX#, в котором перечислены все пакеты на всех томах набора, а также дополнительное поле, указывающее, на каком именно томе находится конкретный пакет. Каждый том в наборе также должен иметь установленную переменную `CD_VOLUME` в файле [.filename]#cdrom.inf#, чтобы bsdinstall мог определить, какой том является каким. Когда пользователь пытается установить пакет, которого нет на текущем диске, bsdinstall предложит ему вставить соответствующий диск. [[distribution]] == Распространение [[dist-ftp]] -=== Серверы FTP +=== Сайты FTP -После того, как релиз был тщательно протестирован и подготовлен к распространению, должен быть обновлён главный FTP-сервер. Все официальные общедоступные серверы FTP-серверы FreeBSD являются зеркалами главного сервера, открытого только другим серверам FTP. Этот сервер известен под именем `ftp-master`. Когда релиз готов, на сервере `ftp-master` должны быть изменены следующие строки: +Когда выпуск тщательно протестирован и упакован для распространения, необходимо обновить главный FTP-сайт. Официальные публичные FTP-сайты FreeBSD являются зеркалами главного сервера, который доступен только другим FTP-сайтам. Этот сервер известен как `ftp-master`. Когда выпуск готов, следующие файлы должны быть изменены на `ftp-master`: [.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/#:: -Установочный каталог FTP, получаемый по команде `make release`. +Устанавливаемый каталог FTP, полученный в результате выполнения `make release`. [.filename]#/pub/FreeBSD/ports/arch/packages-X.Y-release/#:: -Полный комплект построенных пакетов для этого релиза. +Полная сборка пакетов для этого выпуска. [.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools#:: Символическая ссылка на [.filename]#../../../tools#. @@ -320,88 +315,44 @@ Sysinstall поддерживает установку пакетов с нес Символическая ссылка на [.filename]#../../../ports/arch/packages-X.Y-release#. [.filename]#/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso#:: -ISO-образы. Здесь "*" это [.filename]#disc1#, [.filename]#disc2# и так далее. Только если здесь есть [.filename]#disc1# и альтернативный первый установочный CD (например, обрезанная установка без оконной системы), то здесь может быть также и [.filename]#mini#. +Образы ISO. Символ "*" обозначает [.filename]#disc1#, [.filename]#disc2# и так далее. Только если существует [.filename]#disc1# и есть альтернативный первый установочный CD (например, упрощённая установка без графической оболочки), может также присутствовать [.filename]#mini#. -Для получения дополнительной информации о системе зеркальных FTP-серверов FreeBSD, пожалуйста, прочтите статью о extref:{hubs}[Зеркалировании FreeBSD]. +Для получения дополнительной информации об архитектуре зеркал распространения FTP-сайтов FreeBSD, пожалуйста, ознакомьтесь со статьей extref:{hubs}[Поддержка зеркал FreeBSD]. -Может пройти от нескольких часов до двух дней между тем, как обновится `ftp-master`, и на основной массе FTP-серверов 1-го уровня появится новое программное обеспечение, в зависимости от того, в тоже самое ли время пакет был загружен. Обязательно, чтобы выпускающие релиз координировали свои действия с {mirror-announce} до того, как объявлять об общедоступности нового программного обеспечения с серверов FTP. В идеальном случае набор пакетов к релизу должен быть загружен по крайней мере за четыре дня до момента выпуска релиза. Релиз должен быть загружен в промежутке от 24 до 48 часов до момента выхода запланированного релиза с выключенными полномочиями "other". Это позволит зеркалирующим серверам сгрузить его, но никто не сможет получить его с зеркальных серверов. В момент выхода релиза должно быть послано сообщение в адрес {mirror-announce}, говорящее о том, что релиз выпущен и наступило время для открытия доступа на зеркальных серверах. Обязательно вместе со временем укажите и часовой пояс, например, относительно GMT. +Может потребоваться от нескольких часов до двух дней после обновления `ftp-master`, прежде чем большинство FTP-сайтов Tier-1 получат новое программное обеспечение, в зависимости от того, был ли загружен набор пакетов одновременно. Крайне важно, чтобы инженеры по выпуску скоординировались с {mirror-announce} перед объявлением общей доступности нового программного обеспечения на FTP-сайтах. В идеале набор пакетов для выпуска должен быть загружен как минимум за четыре дня до дня выпуска. Выпускные файлы должны быть загружены за 24–48 часов до запланированного времени выпуска с отключёнными разрешениями для "других" пользователей. Это позволит зеркальным сайтам загрузить их, но широкая публика не сможет скачать их с зеркальных сайтов. Письмо должно быть отправлено в {mirror-announce} в момент публикации выпускных файлов, уведомляя о том, что выпуск подготовлен, и указывая время, когда зеркальные сайты должны начать разрешать доступ. Обязательно укажите часовой пояс для указанного времени, например, относительно GMT. [[dist-cdrom]] -=== Тиражирование CD-ROM +=== Репликация CD-ROM -Вскоре появится: Советы по передаче ISO-образов FreeBSD на тиражирование и применяемые меры по контролю качества. +Скоро: Советы по отправке ISO-образов FreeBSD репликатору и меры по обеспечению качества. [[extensibility]] == Расширяемость -Хотя FreeBSD представляет собой законченную операционную систему, ничего не заставляет вас использовать систему только в том виде, который приготовлен нами для распространения. Мы попытались спроектировать систему максимально расширяемой, чтобы она могла выполнять роль платформы, на основе которой можно строить другие коммерческие продукты. Единственным "правилом", которое мы налагаем, является настоятельная рекомендация документировать улучшения, вносимые вами в дистрибутив FreeBSD с нетривиальными изменениями! Сообщество FreeBSD может помогать только пользователям того программного обеспечения, которое распространяем мы. Мы определённо приветствуем улучшения в форме, например, инструментов установки и администрирования, но не можем отвечать на вопросы о них. - -=== Создание модифицированных загрузочных дискет - -Во многих местах имеются сложные условия, которые требуют размещения дополнительных модулей ядра или пользовательских инструментов на установочные дискеты. "Быстрым и неаккуратным" способом сделать это является изменение промежуточного каталога в существующей иерархии при выполнении `make release`: - -* Примените патчи или добавьте дополнительные файлы в каталог построения релиза с изменённых корнем файловой системы. -* `rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59]` -* перестройте man:sysinstall[8], ядро и остальные части системы, которые коснулись ваши изменения. -* `chroot ${CHROOTDIR} ./mk floppies` +Хотя FreeBSD представляет собой законченную операционную систему, ничто не обязывает вас использовать её именно в том виде, в каком мы упаковали её для распространения. Мы постарались разработать систему максимально расширяемой, чтобы она могла служить платформой для создания других коммерческих продуктов. Единственное «правило», которое у нас есть на этот счёт, — если вы собираетесь распространять FreeBSD с существенными изменениями, мы рекомендуем документировать ваши улучшения! Сообщество FreeBSD может оказывать поддержку только пользователям того программного обеспечения, которое мы предоставляем. Мы, безусловно, приветствуем инновации, такие как продвинутые инструменты установки и администрирования, но не можем отвечать на вопросы о них. -Дискеты нового релиза будут находиться в [.filename]#${CHROOTDIR}/R/stage/floppies#. +=== Скриптинг `bsdinstall` -Либо может быть вызвана цель [.filename]#boot.flp# построения или скрипт создания файловой системы, [.filename]#src/release/scripts/doFS.sh#, которые может быть вызван напрямую. - -Локальные патчи могут быть также приложены к построению релиза при помощи задания переменной `LOCAL_PATCH` при выполнении `make release`. - -=== Скрипты `sysinstall` - -Инструмент установки и настройки системы FreeBSD, man:sysinstall[8], может работать по сценарию, полезному для автоматизированной установки в больших компаниях. Эта функциональность может использоваться совместно с технологией Intel(R) PXE[12] для первоначальной установки систем из сети, или с модифицированными загрузочными дискетами со скриптами sysinstall. Пример скрипта для sysinstall доступен в дереве CVS в виде файла [.filename]#src/release/sysinstall/install.cfg#. +Инструмент установки и настройки системы FreeBSD, man:bsdinstall[8], может быть настроен для автоматизированной установки на крупных площадках. Эта функциональность может использоваться совместно с Intel(R) PXE footnote:[extref:{handbook}[Запуск системы по сети (PXE) без использования локальных накопителей, network-diskless]] для загрузки систем по сети. [[lessons-learned]] -== Уроки, извлечённые из FreeBSD 4.4 +== Уроки, извлеченные из FreeBSD 4.4 -Формально процесс подготовки релиза для 4.4 начался 1 августа 2001 года. После этой даты все без исключения изменения в ветке `RELENG_4` FreeBSD подтверждались `{re}`. Первый предварительный релиз для архитектуры x86 был выпущен 16 августа, за ним выходило ещё 4 предварительных релиза, и всё закончилось 18 августа выпуском окончательного релиза. Руководитель службы безопасности очень плотно занимался процессом выпуска в последнюю неделю, так как в предыдущих предварительных релизах были найдены проблемы, касающиеся информационной безопасности. Чуть более чем за месяц в адрес `{re}` поступило более _500_ писем. +Процесс разработки релиза 4.4 официально начался 1 августа 2001 года. После этой даты все коммиты в ветку `RELENG_4` FreeBSD должны были быть явно одобрены `{re}`. Первый релиз-кандидат для архитектуры x86 был выпущен 16 августа, за ним последовали ещё 4 релиз-кандидата, что привело к финальному релизу 18 сентября. Сотрудник по безопасности был очень вовлечён в последнюю неделю процесса, так как несколько проблем безопасности было обнаружено в ранних релиз-кандидатах. Всего за чуть более месяца было отправлено более _500_ писем `{re}`. -Сообщество наших пользователей весьма чётко показало, что безопасность и стабильность релиза FreeBSD не должна приноситься в жертву любым назначенным срокам окончания работ или планируемым датам выхода релиза. Проект FreeBSD за время своего существования значительно вырос, и никогда ранее необходимость в стандартизации процедур подготовки релизов не стояла так остро. Это стало ещё более важно, когда FreeBSD была перенесена на новые аппаратные платформы. +Наше сообщество пользователей ясно дало понять, что безопасность и стабильность выпуска FreeBSD не должны приноситься в жертву из-за самостоятельно установленных сроков или целевых дат выпуска. Проект FreeBSD значительно вырос за время своего существования, и необходимость стандартизированных процедур управления выпусками никогда не была столь очевидной. Это станет ещё более важным по мере переноса FreeBSD на новые платформы. [[future]] -== Направления будущих работ +== Перспективы развития -Нашим работам по подготовке релизов жизненно важно расти вместе с увеличением количества пользователей системы. Вместе с этим мы очень плотно работаем над документированием действий, выполняемых при выпуске релизов FreeBSD. +Для обеспечения масштабирования наших процессов релиз-инжиниринга с растущей пользовательской базой мы прилагаем значительные усилия по документированию процедур, связанных с созданием выпусков FreeBSD. -* _Параллелизм_ - некоторые этапы построения релиза на самом деле выполнять параллельно "затруднительно". Большинство выполняемых задач весьма интенсивно работают с I/O, так что для ускорения процесса `make release` наличие нескольких высокоскоростных дисков гораздо более важно, чем использование нескольких процессоров. Если для различных иерархий в man:chroot[2]-окружении используется несколько дисков, то извлечение из CVS деревьев [.filename]#ports# и [.filename]#doc# может выполняться одновременно с командой `make world` на другом диске. Использование `RAID`-решений (аппаратных или программных) может значительно сократить общее время построения. -* _Кроссплатформенное построение релизов_ - Построить релиз для IA-64 или Alpha на x86-оборудовании? `make TARGET=ia64 release`. -* _Тестирование_ - Нам нужна улучшенная автоматизированная система тестирования корректности для FreeBSD. -* _Инструменты установки_ - Наша программа установки давно пережила свой век. В разработке находятся несколько проектов, которые должны дать улучшенную технологию установки. Одним из таких проектов был libh, целью которого было создание новой интеллектуальной технологии работы с пакетами и программы установки с GUI. +* _Параллелизм_ — Некоторые этапы сборки релиза действительно "тривиально параллельны". Большинство задач очень интенсивно используют ввод-вывод, поэтому наличие нескольких высокоскоростных дисков важнее, чем использование нескольких процессоров для ускорения процесса `make release`. Если в среде man:chroot[2] разные иерархии размещены на разных дисках, то выгрузка CVS для деревьев [.filename]#ports# и [.filename]#doc# может происходить одновременно с выполнением `make world` на другом диске. Использование RAID (аппаратного или программного) может значительно сократить общее время сборки. +* _Кросс-сборка релизов_ - Сборка релиза для IA-64 или Alpha на x86 оборудовании? `make TARGET=ia64 release`. +* _Регрессионное тестирование_ - Нам необходимы более совершенные автоматизированные тесты на корректность для FreeBSD. +* _Инструменты установки_ - Наша программа установки уже давно вышла за рамки своего первоначального срока службы. В разработке находится несколько проектов, призванных обеспечить более продвинутый механизм установки. Проект libh был одним из таких проектов, целью которого было создание интеллектуальной новой системы управления пакетами и программы установки с графическим интерфейсом. [[ackno]] == Благодарности -Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он дал мне возможность взять под свою ответственность некоторые части процесса подготовки релиза FreeBSD 4.4, а также за все годы его работы, сделавшие FreeBSD такой, какой она является сейчас. Конечно, релиз не был бы возможен без той работы, которую проделали `{asami}`, `{steve}`, `{bmah}`, `{nik}`, `{obrien}`, `{kris}`, `{jhb}` и остальные члены сообщества разработчиков FreeBSD. Я также рад выразить благодарность `{rgrimes}` и `{phk}`, а также остальным, работавшим над инструментами подготовки релизов в первые годы существования FreeBSD. Эта статья была также написана под впечатлением документации по подготовке релизов от CSRG[13], NetBSD Project[10] и замечаний Джона Балдвина (John Baldwin) по предлагаемому процессу подготовки релизов[11]. - -[[biblio]] -== Справочная литература - -(1) CVS - Concurrent Versions System http://www.cvshome.org[http://www.cvshome.org] - -(2) CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup[http://www.polstra.com/projects/freeware/CVSup] - -(3) http://pointyhat.FreeBSD.org[http://pointyhat.FreeBSD.org] - -(4) Коллекция портов FreeBSD http://www.FreeBSD.org/ports[http://www.FreeBSD.org/ports] - -(5) extref:{contributors}[Коммиттеры FreeBSD, staff-committers] - -(6) Правление FreeBSD link:https://www.FreeBSD.org/administration/#t-core[https://www.FreeBSD.org/administration/#t-core] - -(7) extref:{handbook}[Руководство FreeBSD] - -(8) GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats[http://www.gnu.org/software/gnats] - -(9) Статистика FreeBSD PR FreeBSD PR Statistics http://www.FreeBSD.org/prstats/[http://www.FreeBSD.org/prstats/] - -(10) NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html[http://www.NetBSD.org/developers/releng/index.html] - -(11) John Baldwin's FreeBSD Release Engineering Proposal http://people.FreeBSD.org/\~jhb/docs/releng.txt[http://people.FreeBSD.org/~jhb/docs/releng.txt] - -(12) PXE Jumpstart Guide link:{pxe}[PXE Guide] - -(13) Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: http://docs.FreeBSD.org/44doc/papers/releng.html[The Release Engineering of 4.3BSD] +Я хотел бы поблагодарить Джордана Хаббарда за предоставленную мне возможность взять на себя часть обязанностей по управлению выпусками для FreeBSD 4.4, а также за всю его работу на протяжении многих лет, которая сделала FreeBSD такой, какая она есть сегодня. Конечно, выпуск не состоялся бы без всей работы, связанной с выпуском, выполненной `{asami}`, `{steve}`, `{bmah}`, `{nik}`, `{obrien}`, `{kris}`, `{jhb}` и остальным сообществом разработчиков FreeBSD. Я также хотел бы поблагодарить `{rgrimes}`, `{phk}` и других, кто работал над инструментами управления выпусками в самые ранние дни FreeBSD. На эту статью повлияли документы по управлению выпусками от CSRG footnote:[Маршалл Кирк МакКузик, Майкл Дж. Карелс и Кит Бостик: link:http://docs.FreeBSD.org/44doc/papers/releng.html[Управление выпусками 4.3BSD]], проекта NetBSD footnote:[Документация разработчика NetBSD: Управление выпусками http://www.NetBSD.org/developers/releng/index.html] и заметки Джона Болдуина с предложениями по процессу управления выпусками. footnote:[Предложение Джона Болдуина по управлению выпусками FreeBSD https://people.FreeBSD.org/~jhb/docs/releng.txt] |