diff options
Diffstat (limited to 'documentation/content/ru/articles/freebsd-releng/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/freebsd-releng/_index.adoc | 758 |
1 files changed, 758 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..d26b1ef841 --- /dev/null +++ b/documentation/content/ru/articles/freebsd-releng/_index.adoc @@ -0,0 +1,758 @@ +--- +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. +|=== |