diff options
Diffstat (limited to 'documentation/content/ru/articles/freebsd-releng/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/freebsd-releng/_index.adoc | 952 |
1 files changed, 952 insertions, 0 deletions
diff --git a/documentation/content/ru/articles/freebsd-releng/_index.adoc b/documentation/content/ru/articles/freebsd-releng/_index.adoc new file mode 100644 index 0000000000..d02aebc780 --- /dev/null +++ b/documentation/content/ru/articles/freebsd-releng/_index.adoc @@ -0,0 +1,952 @@ +--- +authors: + - + author: 'Glen Barber' + email: gjb@FreeBSD.org +description: 'Описывает подход, используемый командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества. В нем описаны инструменты, доступные тем, кто заинтересован в создании настраиваемых релизов FreeBSD для корпоративного внедрения или коммерческой продуктивизации' +organizations: + - + organization: 'The FreeBSD Foundation' + webpage: https://www.freebsdfoundation.org/ + - + organization: 'Rubicon Communications, LLC (Netgate)' + webpage: https://www.netgate.com/ +tags: ["releases", "engineering", "process", "FreeBSD"] +title: 'Подготовка релизов FreeBSD' +trademarks: ["freebsd", "intel", "general", "git"] +--- + += Подготовка релизов FreeBSD +:doctype: article +:toc: macro +:toclevels: 1 +:icons: font +:sectnums: +:sectnumlevels: 6 +:source-highlighter: rouge +:experimental: +:teamBugmeister: FreeBSD Bugmeister Team +:teamDoceng: FreeBSD Documentation Engineering Team +:teamPortmgr: FreeBSD Ports Management Team +:teamPostmaster: FreeBSD Postmaster Team +:teamRe: FreeBSD Release Engineering Team +:teamSecteam: FreeBSD Security Team +:branchHead: main +:branchStable: stable/ +:branchStablex: stable/13 +:branchReleng: releng/ +:branchRelengx: releng/13.0 +:tagReleasex: release/13.0.0 +:branchRevision: 13.0 + +:images-path: articles/freebsd-releng/ + +ifdef::env-beastie[] +ifdef::backend-html5[] +include::shared/authors.adoc[] +include::shared/mirrors.adoc[] +include::shared/releases.adoc[] +include::shared/attributes/attributes-{{% lang %}}.adoc[] +include::shared/{{% lang %}}/teams.adoc[] +include::shared/{{% lang %}}/mailing-lists.adoc[] +include::shared/{{% lang %}}/urls.adoc[] +:imagesdir: ../../../images/{images-path} +endif::[] +ifdef::backend-pdf,backend-epub3[] +include::../../../../shared/asciidoctor.adoc[] +endif::[] +endif::[] + +ifndef::env-beastie[] +include::../../../../../shared/asciidoctor.adoc[] +endif::[] + +[.abstract-title] +Аннотация + +В этой статье описывается процесс разработки релизов проекта FreeBSD. + +''' + +toc::[] + +[[introduction]] +== Введение в процесс разработки релизов FreeBSD + +Разработка FreeBSD следует очень специфичному рабочему процессу. В общем +случае все изменения в базовой системе FreeBSD вносятся в ветку +{branchHead}, которая отражает вершину дерева исходного кода. + +После достаточного периода тестирования изменения могут быть объединены в +ветки {branchStable}. Минимальный срок по умолчанию перед объединением в +ветки {branchStable} составляет три (3) дня. + +Хотя общее правило предписывает выждать минимум три дня перед слиянием из +{branchHead}, существуют особые обстоятельства, при которых может +потребоваться немедленное слияние, например, критическое исправление +безопасности или исправление ошибки, напрямую блокирующей процесс сборки +выпуска. + +Через несколько месяцев, когда количество изменений в ветке {branchStable} +значительно увеличилось, наступает время выпуска следующей версии +FreeBSD. Исторически такие выпуски называются релизами "с точкой". + +Между выпусками из ветвей {branchStable}, примерно каждые два (2) года, +выпуск будет создаваться напрямую из {branchHead}. Исторически такие выпуски +назывались выпуском «точка-ноль (dot-zero)». + +Эта статья освещает рабочий процесс и обязанности команды {teamRe} как для +выпуска "точка-ноль", так и для "промежуточных" выпусков. + +Следующие разделы этой статьи описывают: + +crossref:freebsd-releng[releng-prep, Общая информация и подготовка]:: +Общая информация и подготовка перед началом цикла выпуска. + +crossref:freebsd-releng[releng-website, Изменения на веб-сайте в течение цикла выпуска]:: +Изменения на веб-сайте в течение цикла выпуска + +crossref:freebsd-releng[releng-terms, Терминология выпуска релизов]:: +Терминология и общая информация, такие как "мягкая заморозка кода (code +slush)" и "заморозка кода (code freeze)", используемые в этом документе. + +crossref:freebsd-releng[releng-head, Выпуск релиза от {branchHead}]:: +Процесс Release Engineering для релиза "точка-ноль". + +crossref:freebsd-releng[releng-stable, Выпуск релиза от {branchStable}]:: +Процесс Release Engineering для "точечного" выпуска. + +crossref:freebsd-releng[releng-building, Создание установочных носителей FreeBSD]:: +Информация, относящаяся к конкретным процедурам создания установочного +носителя. + +crossref:freebsd-releng[releng-mirrors, Публикация установочных носителей FreeBSD на зеркалах проекта]:: +Процедуры публикации установочного носителя. + +crossref:freebsd-releng[releng-wrapup, Завершение цикла выпуска]:: +Завершение цикла выпуска. + +[[releng-prep]] +== Общая информация и подготовка + +Примерно за два месяца до начала цикла выпуска команда {teamRe} определяет +график выпуска. График включает в себя различные этапы цикла выпуска, такие +как даты заморозки, даты ветвления и даты сборки. Например: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Веха +| Предполагаемая дата + +|мягкая заморозка {branchHead}: +|May 27, 2016 + +|заморозка {branchHead}: +|June 10, 2016 + +|заморозка {branchHead} KBI: +|June 24, 2016 + +|мягкая заморозка дерева `doc/` [1]: +|June 24, 2016 + +|Ежеквартальная ветка Ports [2]: +|July 1, 2016 + +|Ветка {branchStablex}: +|July 8, 2016 + +|`doc/` tree tag [3]: +|July 8, 2016 + +|Начало сборки BETA1: +|July 8, 2016 + +|Разморозка {branchHead}: +|July 9, 2016 + +|Сборка BETA2 начинается: +|July 15, 2016 + +|Сборка BETA3 начинается [*]: +|July 22, 2016 + +|Ветка `{branchRelengx}`: +|July 29, 2016 + +|Сборка RC1 начинается: +|July 29, 2016 + +|Разморозка {branchStablex}: +|July 30, 2016 + +|Сборка RC2 начинается: +|August 5, 2016 + +|Окончательные сборки пакетов Ports [4]: +|August 6, 2016 + +|Метка релиза портов: +|12 августа 2016 + +|Сборка RC3 начинается [*]: +|12 августа 2016 + +|Сборка RELEASE начинается: +|August 19, 2016 + +|Объявление о ВЫПУСКЕ: +|September 2, 2016 +|=== + +[NOTE] +==== +Отметка "[*]" у элементов означает "по мере необходимости". +==== + +. Мягкая заморозка дерева `doc/` координируется командой {teamDoceng}. +. Используемая квартальная ветка Ports определяется по дате запланированной + окончательной сборки `RC`. Новая квартальная ветка создаётся в первый день + квартала, поэтому этот показатель следует учитывать, принимая во внимание + этапы цикла выпуска. Квартальная ветка создаётся командой {teamPortmgr}. +. Для дерева исходного кода `doc/` tag делается командой {teamDoceng}. +. Окончательная сборка пакета Ports выполняется командой {teamPortmgr} после + финальной (или ожидаемой финальной) сборки `RC`. + +[NOTE] +==== +Если выпуск создаётся из существующей ветки {branchStable}, дату заморозки +KBI можно исключить, так как KBI уже считается замороженным в устоявшихся +ветках {branchStable}. +==== + +При написании графика цикла выпуска необходимо учитывать ряд факторов, +особенно этапы, на которые целевая дата зависит от предопределенных этапов, +от которых существует зависимость. Например, тег выпуска коллекции портов +берется из активной квартальной ветки на момент последнего `RC`. Это +частично определяет, какая квартальная ветка используется, когда может быть +создан тег выпуска и какая версия дерева портов используется для финальной +сборки `RELEASE`. + +После общего согласования расписания команда {teamRe} отправляет расписание +разработчикам FreeBSD по электронной почте. + +Вполне типично, что многие разработчики сообщают команде {teamRe} о +различных работах в процессе выполнения. В некоторых случаях может быть +запрошено продление для работы в процессе, а в других случаях может быть +сделан запрос на "общее одобрение" для определенного подмножества дерева. + +При таких запросах важно убедиться, что обсуждаются сроки (даже если они +приблизительные). Для общих одобрений следует четко указать +продолжительность действия такого одобрения. Например, разработчик FreeBSD +может запросить общее одобрение с начала периода мягкой заморозки кода до +начала сборок `RC`. + +[NOTE] +==== +Для отслеживания общих одобрений команда {teamRe} использует внутренний +репозиторий, в котором ведется журнал таких запросов. В нем указывается +область, на которую распространяется общее одобрение, автор(ы), срок +действия одобрения и причина его выдачи. Например, может быть предоставлено +общее одобрение для [.filename]#release/doc/# всем членам {teamRe} до +финального `RC` для обновления примечаний к выпуску и другой связанной с +выпуском документации. +==== + +[NOTE] +==== +Команда {teamRe} также использует этот репозиторий для отслеживания +ожидающих одобрения запросов, полученных непосредственно перед началом +различных сборок во время цикла выпуска, при этом Инженер по выпускам +указывает срок отсечки с помощью электронного письма разработчикам FreeBSD. +==== + +В зависимости от рассматриваемого набора кода и общего влияния этого набора +кода на FreeBSD в целом, такие запросы могут быть одобрены или отклонены +командой {teamRe}. + +То же самое относится к расширениям для незавершённых работ. Например, +незавершённая работа над новым драйвером устройства, который в остальном +изолирован от остального дерева, может получить расширение. Однако новый +планировщик может оказаться неосуществимым, особенно если такие значительные +изменения отсутствуют в другой ветке. + +Расписание также добавляется на сайт проекта в репозитории `doc/`, в файле +[.filename]#~/website/content/en/releases/{branchRevision}R/schedule.adoc#. +Этот файл постоянно обновляется по мере прохождения цикла выпуска. + +[NOTE] +==== +В большинстве случаев файл [.filename]#schedule.adoc# можно скопировать из +предыдущего релиза и обновить соответствующим образом. +==== + +В дополнение к добавлению [.filename]#schedule.adoc# на веб-сайт, файл +[.filename]#~/shared/releases.adoc# также обновляется, чтобы добавить ссылку +на расписание на различные подстраницы, а также включить ссылку на +расписание на главной странице веб-сайта проекта. + +Расписание также доступно по ссылке из файла +[.filename]#~/website/content/en/releng/_index.adoc#. + +Примерно за месяц до запланированной "мягкой заморозки кода" команда +{teamRe} отправляет напоминание разработчикам FreeBSD. + +[[releng-terms]] +== Терминология выпуска релизов + +В этом разделе описана часть терминологии, используемой в остальной части +данного документа. + +[[releng-terms-code-slush]] +=== Мягкая заморозка кода + +Хотя мягкая заморозка кода не является полной заморозкой дерева, команда +{teamRe} просит отдавать приоритет исправлению ошибок в существующей кодовой +базе перед добавлением новых функций. + +Мягкая заморозка кода не требует подтверждений коммитов в ветку. + +[[releng-terms-code-freeze]] +=== Заморозка кода + +Замораживание кода означает момент времени, когда все коммиты в ветку +требуют явного одобрения от {teamRe}. + +Репозиторий FreeBSD Git содержит несколько хуков для выполнения проверок +перед тем, как изменения будут зафиксированы в дереве. Один из этих хуков +проверяет, требуются ли специальные разрешения для фиксации изменений в +определённой ветке. + +Для обеспечения утверждения коммитов командой {teamRe}, команда Release +Engineering должна утверждать любые изменения в ветке. В этом случае журнал +коммитов должен содержать строку `Approved by: re (логин)`, где "логин" — +это идентификатор утверждающего. + +[NOTE] +==== +Во время заморозки кода участники проекта FreeBSD должны следовать +link:https://wiki.freebsd.org/Releng/ChangeRequestGuidelines[Рекомендациям +по запросам изменений]. +==== + +[[releng-terms-kbi-freeze]] +=== Замораживание KBI/KPI + +KBI/KPI стабильность подразумевает, что вызов функции в двух разных релизах +программного обеспечения, реализующего эту функцию, приводит к одинаковому +конечному состоянию. Вызывающая сторона, будь то процесс, поток или функция, +ожидает, что функция будет работать определённым образом, в противном случае +стабильность KBI/KPI на ветке нарушается. + +[[releng-website]] +== Изменения на веб-сайте в течение цикла выпуска + +Этот раздел описывает изменения на веб-сайте, которые должны происходить по +мере развития цикла выпуска. + +[NOTE] +==== +Файлы, указанные в этом разделе, относятся к ветке `{branchHead}` +репозитория `doc`. +==== + +[[releng-website-prerelease]] +=== Изменения на веб-сайте перед началом цикла выпуска + +Когда график цикла выпуска становится доступным, эти файлы необходимо +обновить, чтобы включить различные функции на веб-сайте проекта FreeBSD: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#~/shared/releases.adoc# +|Изменить `beta-upcoming` с `IGNORE` на `INCLUDE` + +|[.filename]#~/shared/releases.adoc# +|Изменить `beta-testing` с `IGNORE` на `INCLUDE` + +|=== + +[[releng-website-beta-rc]] +=== Изменения на веб-сайте в период `BETA` или `RC` + +При переходе от `PRERELEASE` к `BETA` эти файлы необходимо обновить, чтобы +включить блок "Help Test (Помогите протестировать)" на странице +загрузки. Все файлы указаны относительно [.filename]#head/# в репозитории +`doc`: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#~/shared/releases.adoc# +|Обновите `betarel-vers` до `BETA__1__` + +|[.filename]#~/website/data/en/news/news.toml# +|Добавьте запись, объявляющую о `BETA` + +|[.filename]#~/website/static/security/advisory-template.txt# +|Добавьте новую `BETA`, `RC` или финальную `RELEASE` в шаблон + +|[.filename]#~/website/static/security/errata-template.txt# +|Добавьте новую `BETA`, `RC` или финальную `RELEASE` в шаблон +|=== + +После создания ветки {branchRelengx} необходимо добавить различные +документы, связанные с выпуском, в репозиторий `doc/`. + +[NOTE] +==== +Соответствующие документы, связанные с выпусками, находятся в репозитории +[.filename]#doc# для FreeBSD 12.x и более поздних версий. +==== + +[[releng-ports-beta-rc]] +=== Изменения в портах во время `BETA`, `RC` и финального `RELEASE` + +Для каждой сборки в течение цикла выпуска файлы `MANIFEST`, содержащие +`SHA256` для различных наборов дистрибутива, таких как `base.txz`, +`kernel.txz` и других, добавляются в порт +package:misc/freebsd-release-manifests[]. Это позволяет другим утилитам, +кроме , таким как package:ports-mgmt/poudriere[], безопасно использовать эти +наборы дистрибутива, предоставляя механизм для проверки контрольных сумм. + +[[releng-head]] +== Выпуск релиза от {branchHead} + +Этот раздел описывает общие процедуры цикла выпуска FreeBSD из ветки +{branchHead}. + +[[releng-head-builds-alpha]] +=== FreeBSD "`ALPHA`" сборки + +Начиная с цикла выпуска FreeBSD 10.0-RELEASE, было введено понятие сборок +"`ALPHA`". В отличие от сборок `BETA` и `RC`, сборки `ALPHA` не включены в +график выпуска FreeBSD. + +Идея сборок `ALPHA` заключается в предоставлении регулярных сборок FreeBSD +до создания ветки {branchStable}. + +Снимки состояния `ALPHA` FreeBSD должны собираться примерно раз в неделю. + +Для первой сборки `ALPHA` значение `BRANCH` в +[.filename]#sys/conf/newvers.sh# необходимо изменить с `CURRENT` на +`ALPHA1`. Для последующих сборок `ALPHA` увеличивайте каждое значение +`ALPHA__N__` на единицу. + +См. crossref:freebsd-releng[releng-building, Сборка установочных носителей +FreeBSD] для получения информации о сборке образов `ALPHA`. + +[[releng-head-branching]] +=== Создание ветки {branchStablex} + +При создании ветки {branchStable} необходимо внести несколько изменений как +в новой ветке {branchStable}, так и в ветке {branchHead}. Указанные файлы +относятся к корню репозитория. Чтобы создать новую ветку {branchStablex} в +Git: + +[NOTE] +==== +Убедитесь, что вы находитесь в ветке {branchHead} +==== + +[source, shell, subs="attributes"] +.... +% git checkout -b {branchStablex} +.... + +После создания ветки {branchStablex} внесите следующие изменения: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#UPDATING# +|Обновите версию FreeBSD и удалите уведомление о `WITNESS` + +|[.filename]#contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h# +a| + +[source,shell,subs="attributes"] +.... +#ifndef MALLOC_PRODUCTION +#define MALLOC_PRODUCTION +#endif +.... + +|[.filename]#lib/clang/llvm.build.mk# +|Раскомментируйте `-DNDEBUG` + +|[.filename]#sys/\*/conf/GENERIC*# +|Удалите поддержку отладки + +|[.filename]#sys/*/conf/MINIMAL# +|Удалите поддержку отладки + +|[.filename]#release/release.conf.sample# +|Обновите `SRCBRANCH` + +|[.filename]#sys/*/conf/GENERIC-NODEBUG# +|Удалите следующие параметры конфигурации ядра + +|[.filename]#sys/arm/conf/std.arm*# +|Удалите отладочные опции + +|[.filename]#sys/conf/newvers.sh# +|Обновите значение `BRANCH`, чтобы оно соответствовало `BETA1` + +|[.filename]#share/mk/src.opts.mk# +|Переместите `REPRODUCIBLE_BUILD` из `\__DEFAULT_NO_OPTIONS` в `__DEFAULT_YES_OPTIONS` + +|[.filename]#share/mk/src.opts.mk# +|Переместите `LLVM_ASSERTIONS` из `\__DEFAULT_YES_OPTIONS` в `__DEFAULT_NO_OPTIONS` + +|[.filename]#libexec/rc/rc.conf# +|Установите `dumpdev` с `AUTO` на `NO` (это настраивается для тех, кто хочет включить его по умолчанию) + +|[.filename]#release/Makefile# +|Удалите записи `debug.witness.trace` +|=== + +Затем в ветке {branchHead}, которая теперь станет новой основной версией: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#UPDATING# +|Обновите версию FreeBSD + +|[.filename]#sys/conf/newvers.sh# +|Обновите значение `BRANCH`, чтобы оно соответствовало `CURRENT`, и увеличьте `REVISION` + +|[.filename]#Makefile.inc1# +|Обновите `TARGET_TRIPLE` и `MACHINE_TRIPLE` + +|[.filename]#sys/sys/param.h# +|Обновите `__FreeBSD_version` + +|[.filename]#gnu/usr.bin/cc/cc_tools/freebsd-native.h# +|Обновите `FBSD_MAJOR` и `FBSD_CC_VER` + +|[.filename]#contrib/gcc/config.gcc# +|Добавьте раздел `freebsdversion.h` + +|[.filename]#lib/clang/llvm.build.mk# +|Обновите значение `OS_VERSION` + +|[.filename]#lib/clang/freebsd_cc_version.h# +|Обновите `FREEBSD_CC_VERSION` + +|[.filename]#lib/clang/include/lld/Common/Version.inc# +|Обновите `LLD_REVISION_STRING` + +|[.filename]#Makefile.libcompat# +|Обновите `LIB32CPUFLAGS` +|=== + +[[releng-stable]] +== Выпуск релиза от {branchStable} + +Этот раздел описывает общие процедуры цикла выпуска FreeBSD из установленной +ветки {branchStable}. + +[[releng-stable-slush]] +=== Мягкая заморозка кода ветки `stable` FreeBSD + +В рамках подготовки к заморозке кода в ветке `stable` необходимо обновить +несколько файлов, чтобы отразить официальное начало цикла выпуска. Эти файлы +находятся в корневом каталоге ветки stable: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#sys/conf/newvers.sh# +|Обновите значение `BRANCH`, чтобы отразить `PRERELEASE` + +|[.filename]#Makefile.inc1# +|Обновите `TARGET_TRIPLE` + +|[.filename]#lib/clang/llvm.build.mk# +|Обновите `OS_VERSION` + +|[.filename]#Makefile.libcompat# +|Обновите `LIB32CPUFLAGS` +|=== + +[[releng-stable-builds-beta]] +=== Сборки FreeBSD `BETA` + +После периода мягкой заморозки следующая фаза цикла выпуска — это заморозка +кода. На этом этапе все коммиты в стабильную ветку требуют явного одобрения +от {teamRe}. Это контролируется {git-admin-email}, который управляет +репозиторием. + +[NOTE] +==== +Существует два общих исключения, когда не требуется подтверждение коммита во +время цикла выпуска. Первое — любые изменения, которые необходимо +закоммитить инженеру выпуска для продолжения ежедневной работы цикла +выпуска. Второе — исправления безопасности, которые могут возникнуть во +время цикла выпуска. +==== + +После вступления в силу заморозки кода следующая сборка из ветки помечается +как `BETA1`. Это делается путём изменения значения `BRANCH` в файле +[.filename]#sys/conf/newvers.sh# с `PRERELEASE` на `BETA1`. + +После этого начинается первая сборка `BETA`. Последующие сборки `BETA` не +требуют обновления каких-либо файлов, кроме +[.filename]#sys/conf/newvers.sh#, с увеличением номера сборки `BETA`. + +[[releng-stable-branching]] +=== Создание ветки {branchRelengx} + +Когда первая сборка `RC` (Release Candidate) готова к началу, создается +ветка {branchReleng}. Это многоэтапный процесс, который должен выполняться в +определенном порядке, чтобы избежать аномалий, таких как пересечения +значений `__FreeBSD_version`, например. Указанные ниже пути относятся к +корню репозитория. Порядок коммитов и что нужно изменить: + +[NOTE] +==== +Убедитесь, что вы находитесь в ветке {branchStablex} +==== + +[source, shell, subs="attributes"] +.... +% git checkout -b {branchRelengx} +.... + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#sys/conf/newvers.sh# +|Измените `BETA__X__` на `RC1` + +|[.filename]#sys/sys/param.h# +|Обновите `__FreeBSD_version` + +|[.filename]#sys/conf/kern.opts.mk# +|Переместите `REPRODUCIBLE_BUILD` из `__DEFAULT_NO_OPTIONS` в `__DEFAULT_YES_OPTIONS` + +|[.filename]#etc/pkg/FreeBSD.conf# +|Замените `latest` на `quarterly` в качестве расположения репозитория пакетов по умолчанию + +|[.filename]#release/pkg_repos/release-dvd.conf# +|Замените `latest` на `quarterly` в качестве расположения репозитория пакетов по умолчанию + +|[.filename]#sys/conf/newvers.sh# +|Обновите `BETA__X__` на `PRERELEASE` + +|[.filename]#sys/sys/param.h# +|Обновите `__FreeBSD_version` +|=== + +Затем {git-admin-email} добавляет новых утверждающих для ветки releng, как +это было сделано для ветки stable. + +[source, shell, subs="attributes"] +.... +% git add . +% git commit +.... + +Теперь, когда существуют два новых значения `__FreeBSD_version`, также +обновите файл +[.filename]#~/documentation/content/en/books/porters-handbook/versions/chapter.adoc# +в репозитории проекта документации. + +После завершения первой сборки `RC` и её тестирования ветку {branchStable} +можно «разморозить» с помощью {git-admin-email}. + +После появления первой версии `RC` необходимо отправить письмо команде +{teamBugmeister}, чтобы добавить новую версию FreeBSD `-RELEASE` в список +`versions`, доступный в выпадающем меню трекера ошибок. + +[[releng-building]] +== Создание установочных носителей FreeBSD + +Этот раздел описывает общие процедуры создания снимков разработки и выпусков +FreeBSD. + +[[releng-build-scripts]] +=== Скрипты сборки релизов + +До выхода FreeBSD 9.0-RELEASE файл [.filename]#src/release/Makefile# был +обновлен для поддержки , а скрипт +[.filename]#src/release/generate-release.sh# был добавлен в качестве обертки +для автоматизации вызова целей. + +До выхода FreeBSD 9.2-RELEASE был представлен +[.filename]#src/release/release.sh#, который, основываясь на +[.filename]#src/release/generate-release.sh#, включал поддержку указания +конфигурационных файлов для переопределения различных опций и переменных +окружения. Поддержка конфигурационных файлов обеспечила возможность +кросс-сборки каждого архитектурного варианта для релиза путем указания +отдельного конфигурационного файла для каждого вызова. + +В качестве краткого примера использования +[.filename]#src/release/release.sh# для сборки одного релиза в +[.filename]#/scratch#: + +[source, shell, subs="attributes"] +.... +# /bin/sh /usr/src/release/release.sh +.... + +В качестве краткого примера использования +[.filename]#src/release/release.sh# для сборки единого кросс-собранного +выпуска с использованием другого целевого каталога, создайте +пользовательский [.filename]#release.conf#, содержащий: + +[.programlisting, subs="attributes"] +.... +# release.sh configuration for powerpc/powerpc64 +CHROOTDIR="/scratch-powerpc64" +TARGET="powerpc" +TARGET_ARCH="powerpc64" +KERNEL="GENERIC64" +.... + +Затем выполните [.filename]#src/release/release.sh# следующим образом: + +[source, shell, subs="attributes"] +.... +# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf +.... + +См. [.filename]#src/release/release.conf.sample# для получения +дополнительных сведений и примеров использования. + +[[releng-build-release]] +=== Сборка релизов FreeBSD + +В течение цикла выпуска копии файлов [.filename]#CHECKSUM.SHA512# и +[.filename]#CHECKSUM.SHA256# для каждой архитектуры сохраняются во +внутреннем репозитории {teamRe}, а также включаются в различные рассылки с +объявлениями. Каждый файл [.filename]#MANIFEST#, содержащий хеши +[.filename]#base.txz#, [.filename]#kernel.txz# и других, также добавляется в +пакет package:misc/freebsd-release-manifests[] в Коллекции портов. + +В подготовке к сборке выпуска необходимо обновить несколько файлов: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл для редактирования +| Что изменить + +|[.filename]#sys/conf/newvers.sh# +|Обновите значение `BRANCH` на `RELEASE` + +|[.filename]#UPDATING# +|Добавьте предполагаемую дату объявления + +|[.filename]#lib/csu/common/crtbrand.S# +|Замените `__FreeBSD_version` на значение из [.filename]#sys/sys/param.h# +|=== + +После сборки окончательного `RELEASE`, ветка {branchRelengx} помечается как +{tagReleasex}, используя ревизию, из которой был собран +`RELEASE`. Аналогично созданию веток {branchStablex} и {branchRelengx}, это +делается с помощью `git tag`. Из корня репозитория: + +[NOTE] +==== +Убедитесь, что вы находитесь в ветке {branchRelengx} +==== + +[source, shell, subs="attributes"] +.... +% git tag {tagReleasex} +.... + +[[releng-mirrors]] +== Публикация установочных носителей FreeBSD на зеркалах проекта + +Этот раздел описывает процедуру публикации снимков разработки FreeBSD и +выпусков на зеркала Проекта. + +[[releng-mirrors-staging]] +=== Подготовка образов установочных носителей FreeBSD + +Этап подготовки (staging) снимков и выпусков FreeBSD — это двухэтапный +процесс: + +* Создание структуры каталогов, соответствующей иерархии на `ftp-master` ++ +Если `EVERYTHINGISFINE` определено в конфигурационных файлах сборки, +[.filename]#main.conf# в случае скриптов сборки, упомянутых выше, это +происходит автоматически после завершения сборки, создавая структуру +каталогов в [.filename]#${DESTDIR}/R/ftp-stage# с путями, соответствующими +ожидаемым на `ftp-master`. Это эквивалентно выполнению следующего в +директории: ++ +[source, shell, subs="attributes"] +.... +# make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage +.... ++ +После сборки каждой архитектуры скрипт [.filename]#thermite.sh# выполнит +синхронизацию [.filename]#${DESTDIR}/R/ftp-stage# с билда в директории +[.filename]#/snap/ftp/snapshots# или [.filename]#/snap/ftp/releases# на +хосте сборки, соответственно. +* Копирование файлов в промежуточный каталог на `ftp-master` перед + перемещением файлов в [.filename]#pub/# для начала распространения на + зеркала Проекта ++ +После завершения всех сборок каталог [.filename]#/snap/ftp/snapshots# (или +[.filename]#/snap/ftp/releases# для релиза) опрашивается `ftp-master`-ом с +использованием rsync для передачи в [.filename]#/archive/tmp/snapshots# или +[.filename]#/archive/tmp/releases#, соответственно. ++ +[NOTE] +==== +На `ftp-master` в инфраструктуре проекта FreeBSD этот шаг требует доступа +уровня `root`, так как он должен выполняться от имени пользователя +`archive`. +==== + +[[releng-mirrors-publishing]] +=== Публикация установочных носителей FreeBSD + +Как только образы размещены в [.filename]#/archive/tmp/#, они готовы к +публикации путем размещения в [.filename]#/archive/pub/FreeBSD#. Для +уменьшения времени распространения используются жесткие ссылки из +[.filename]#/archive/tmp# в [.filename]#/archive/pub/FreeBSD#. + +[NOTE] +==== +Для эффективной работы и [.filename]#/archive/tmp#, и +[.filename]#/archive/pub# должны находиться в одной логической файловой +системе. +==== + +Однако есть оговорка: после этого необходимо использовать rsync для +исправления символических ссылок в +[.filename]#pub/FreeBSD/snapshots/ISO-IMAGES#, которые будут заменены на +жёсткие ссылки, что увеличит время распространения. + +[NOTE] +==== +Как и на этапе подготовки, это требует доступа уровня `root`, так как данный +шаг должен быть выполнен от имени пользователя `archive`. +==== + +Как пользователь `archive`: + +[source, shell, subs="attributes"] +.... +% cd /archive/tmp/snapshots +% pax -r -w -l . /archive/pub/FreeBSD/snapshots +% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/ +.... + +Замените _снимки_ на _релизы_ там, где это уместно. + +[[releng-wrapup]] +== Завершение цикла выпуска + +Этот раздел описывает общие задачи после выпуска. + +[[releng-wrapup-en]] +=== Уведомления об исправлениях после выпуска + +По мере приближения цикла выпуска к завершению часто появляются несколько +кандидатов в EN (Errata Notice — уведомления об ошибках) для устранения +проблем, обнаруженных на поздних этапах цикла. После выпуска {teamRe} и +{teamSecteam} пересматривают изменения, которые не были одобрены до +финального выпуска, и, в зависимости от масштаба рассматриваемого изменения, +могут выпустить EN. + +[NOTE] +==== +Фактический процесс выпуска EN обрабатывается командой {teamSecteam}. +==== + +Для запроса уведомления об ошибке после завершения цикла выпуска разработчик +должен заполнить https://www.freebsd.org/security/errata-template.txt[шаблон +уведомления об ошибке], в частности разделы `Предыстория`, `Описание +проблемы`, `Последствия` и, если применимо, `Обходное решение`. + +Заполненный шаблон уведомления об ошибке следует отправить по электронной +почте вместе с патчем для ветки {branchReleng} или списком ревизий из ветки +{branchStable}. + +Для запросов на уведомления об ошибках (Errata Notice), поступающих сразу +после выпуска, запрос следует отправлять по электронной почте как в +{teamRe}, так и в {teamSecteam}. После того как ветка {branchReleng} +передана {teamSecteam}, как описано в +crossref:freebsd-releng[releng-wrapup-handoff, Передача {teamSecteam}], +запросы на уведомления об ошибках следует направлять в {teamSecteam}. + +[[releng-wrapup-handoff]] +=== Передача в {teamSecteam} + +Примерно через две недели после выпуска релиза инженер по релизам обновляет +репозиторий Git, изменяя утверждающего с команды инженеров по релизам на +офицера безопасности для ветки `{branchRelengx}`. + +[[releng-eol]] +== Конец срока поддержки выпуска + +Этот раздел описывает файлы, связанные с веб-сайтом, которые необходимо +обновить, когда выпуск достигает EoL (End-of-Life). + +[[releng-eol-website]] +=== Обновления веб-сайта для прекращения поддержки + +Когда выпуск достигает конца жизненного цикла, ссылки на этот выпуск должны +быть удалены и/или обновлены на веб-сайте: + +[.informaltable] +[cols="1,1", frame="none", options="header"] +|=== +| Файл +| Что изменить + +|[.filename]#~/website/themes/beastie/layouts/index.html# +|Удалите ссылки на `u-relXXX-announce` и `u-relXXX-announce`. + +|[.filename]#~/website/content/en/releases/_index.adoc# +|Переместите переменные `u-relXXX-*` из списка поддерживаемых выпусков в список Устаревших выпусков. + +|[.filename]#~/website/content/en/releng/_index.adoc# +|Обновите соответствующую ветку releng, чтобы отразить, что ветка больше не поддерживается. + +|[.filename]#~/website/content/en/security/_index.adoc# +|Удалить ветку из списка поддерживаемых веток. + +|[.filename]#~/website/content/en/security/unsupported.adoc# +|Добавить ветку в список неподдерживаемых веток. + +|[.filename]#~/website/content/en/where.adoc# +|Удалите URL-адреса для выпуска. + +|[.filename]#~/website/themes/beastie/layouts/partials/sidenav.html# +|Удалите ссылки на `u-relXXX-announce` и `u-relXXX-announce`. + +|[.filename]#~/website/static/security/advisory-template.txt# +|Удалите ссылки на ветку release и releng. + +|[.filename]#~/website/static/security/errata-template.txt# +|Удалите ссылки на ветку release и releng. +|=== |