-До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [ crossref:dev-model[thesis, Saers,2003]].
+До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [crossref:dev-model[thesis, "Saers, 2003"]].
Я хотел бы поблагодарить следующих людей за то, что они нашли время объяснить мне непонятные моменты и проверить документ.
@@ -98,15 +98,15 @@
[[overview]]
== Обзор
-Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [ crossref:dev-model[brooks, Brooks, 1995]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за счёт предоставления актуального описания проекта.
+Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [crossref:dev-model[brooks,"Brooks, 1995"]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за счёт предоставления актуального описания проекта.
-Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [ crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор того, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
+Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [ crossref:dev-model[bsd-election2002,"FreeBSD, 2002B"]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор того, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
-Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
+Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [crossref:dev-model[jorgensen2001,"Jørgensen, 2001"]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
После определения используемых терминов в этом документе будет описана организационная структура (включая описания ролей и линии коммуникации), рассмотрена модель методологии, а после представления инструментов, используемых для контроля процессов, будут описаны определённые процессы. В заключение будут представлены основные подпроекты проекта FreeBSD.
-[ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в рамках проекта
+[ crossref:dev-model[freebsd-developer-handbook, "FreeBSD, 2002A"]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в рамках проекта
[[definitions]]
== Определения
@@ -114,7 +114,7 @@
[[ref-activity]]
=== Активность
-"Активность" — это элемент работы, выполняемый в ходе проекта [ crossref:dev-model[ref-pmbok, PMI, 2000]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
+"Активность" — это элемент работы, выполняемый в ходе проекта [ crossref:dev-model[ref-pmbok, "PMI, 2000"]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
[[def-process]]
=== Процесс
@@ -124,12 +124,12 @@
[[ref-hat]]
=== Роль (hat)
-"Hat" (шляпа) является синонимом роли. Роль имеет определённые обязанности в процессе и ответственность за результат процесса. Роль выполняет действия. Четко определено, по каким вопросам участники проекта и люди вне проекта должны обращаться к ответственному, выполняющему эту роль.
+"Hat" (шляпа) является синонимом роли. Роль имеет определённые обязанности в процессе и ответственность за результат процесса. Роль выполняет действия. Чётко определено, по каким вопросам участники проекта и люди вне проекта должны обращаться к ответственному, выполняющему эту роль.
[[ref-outcome]]
=== Результат
-«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [ crossref:dev-model[ref-pmbok, PMI, 2000]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
+«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [ crossref:dev-model[ref-pmbok, "PMI, 2000"]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
[[ref-freebsd]]
=== FreeBSD
@@ -159,7 +159,7 @@
|~3000
|===
-Количество коммиттеров было определено путем анализа журналов CVS с 1 января 2004 года по 31 декабря 2004 года, а список участников — путем просмотра перечня внесенных изменений и отчётов о проблемах.
+Количество коммиттеров было определено путем анализа журналов CVS с 1 января 2004 года по 31 декабря 2004 года, а список участников — путем просмотра перечня внесённых изменений и отчётов о проблемах.
Основной ресурс сообщества FreeBSD — это его разработчики: коммиттеры и контрибьюторы. Именно их вклад позволяет проекту развиваться. Обычные разработчики называются участниками (контрибьюторами). По состоянию на 1 января 2003 года в проекте насчитывается около 5500 контрибьюторов.
@@ -179,27 +179,27 @@
| Количество людей
|Основные участники
-|
+|
|9
|Коммиттеры
|Базовый
|164
-|
+|
|Docs
|45
-|
+|
|Порты
|166
-|
+|
|Total
|374
|Участники
-|
+|
|~3000
|===
@@ -234,7 +234,7 @@
|программирование
|рецензирование
-|
+|
|рецензирование
|предварительная проверка перед коммитом
@@ -253,11 +253,11 @@
|программирование
|релиз для производства
-|
+|
|программирование
|===
-"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [ crossref:dev-model[jorgensen2001, "Jørgensen, 2001"]].
Это модель для одного изменения, которая показывает, что после написания кода разработчики ищут рецензирование сообщества и пытаются интегрировать это изменение в свои собственные системы. После интеграции изменения в версию разработки, называемую FreeBSD-CURRENT, оно тестируется многими пользователями и разработчиками сообщества FreeBSD. После достаточного тестирования оно объединяется с производственной версией, называемой FreeBSD-STABLE. Если каждая стадия не завершена успешно, разработчику необходимо вернуться, внести изменения в код и перезапустить процесс. Интеграция изменения в -CURRENT или -STABLE называется выполнением коммита.
@@ -295,11 +295,11 @@
| Следующие минорные выпуски
|...
-|
-|
+|
+|
|3.0 Current (ветка разработки)
-|
+|
|Ветки Releng 3: выпуски с 3.0 Release по 3.5 Release, ведущие к выпуску 3.5.1 Release и последующей ветке 3 Stable
|4.0 Current (ветка разработки)
@@ -312,15 +312,15 @@
|6.0 Current (ветка разработки)
|Релиз 5.3
-|
+|
|...
-|
-|
+|
+|
|===
-Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [ crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
+Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [ crossref:dev-model[freebsd-releng,"FreeBSD, 2002E"]]
«Основной выпуск» всегда создаётся из ветки -CURRENT. Однако ветка -CURRENT не обязательно должна разветвляться в этот момент, а может сосредоточиться на стабилизации. Примером этого является то, что после 3.0-RELEASE, 3.1-RELEASE также был продолжением ветки -CURRENT, и -CURRENT не стал настоящей веткой разработки до тех пор, пока не был выпущен этот релиз и не была создана ветка 3-STABLE. Когда -CURRENT снова становится веткой разработки, за ним может следовать только основной выпуск. Ожидается, что ветка 5-STABLE будет отделена от 5.0-CURRENT примерно на момент выпуска 5.3-RELEASE. Только после отделения 5-STABLE ветка разработки получит название 6.0-CURRENT.
@@ -357,19 +357,19 @@
[[role-contributor]]
==== Участник (контрибьютор)
-Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [ crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
+Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [ crossref:dev-model[freebsd-contributors, "FreeBSD, 2002F"]]
[[role-committer]]
==== Коммиттер
-Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
+Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [ crossref:dev-model[freebsd-developer-handbook, "FreeBSD, 2000A"]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
Стоит отметить, что нет технических препятствий, которые могли бы помешать кому-либо, получившему права на коммиты в основном или подпроекте, делать коммиты в частях исходного кода проекта, для которых у коммиттера нет явного разрешения на изменение. Однако, при желании внести изменения в части, с которыми коммиттер ранее не работал, следует изучить логи, чтобы понять, что происходило в этой области ранее, а также прочитать файл MAINTAINERS, чтобы узнать, есть ли у сопровождающего этой части какие-либо особые требования к внесению изменений в код.
[[role-core]]
==== Основная команда (Core Team)
-Основная команда избирается коммиттерами из числа коммиттеров и выполняет функции совета директоров проекта FreeBSD. Она повышает активных участников до коммиттеров, назначает людей на четко определённые роли (hats) и является окончательным арбитром при принятии решений о направлении развития проекта. На 1 июля 2004 года в состав основной команды входило 9 членов. Выборы проводятся каждые два года.
+Основная команда избирается коммиттерами из числа коммиттеров и выполняет функции совета директоров проекта FreeBSD. Она повышает активных участников до коммиттеров, назначает людей на чётко определённые роли (hats) и является окончательным арбитром при принятии решений о направлении развития проекта. На 1 июля 2004 года в состав основной команды входило 9 членов. Выборы проводятся каждые два года.
[[role-maintainer]]
==== Сопровождение
@@ -404,7 +404,7 @@
[[role-release-coordination]]
==== Координация выпусков
-Обязанности команды выпуска релизов включают
+Обязанности команды подготовки релизов включают
* Установка, публикация и соблюдение графика выпуска официальных релизов
* Документирование и формализация процедур выпуска релизов
@@ -415,7 +415,7 @@
Дополнительная информация о процессе разработки доступна в разделе crossref:dev-model[process-release-engineering, Выпуск релизов].
[[role-releng]]
-Роль поддерживается: командой выпуск релизов (Release Engineering) mailto:re@FreeBSD.org[re@FreeBSD.org]. https://www.freebsd.org/releng/charter/[ Устав Release Engineering].
+Роль поддерживается: командой подготовки релизов (Release Engineering) mailto:re@FreeBSD.org[re@FreeBSD.org]. https://www.freebsd.org/ru/releng/charter/[ Устав Команды подготовки релизов].
[[role-pr-cr]]
==== Отношения с общественностью и корпоративные связи
@@ -552,9 +552,7 @@
Когда участник отправляет фрагмент кода, принимающий коммиттер может предложить предоставить этому участнику права на коммит. Если он рекомендует это основной команде (Core Team), команда проводит голосование по этой рекомендации. Если голосование завершается в пользу предложения, новому коммиттеру назначается наставник, и новый коммиттер должен отправить свои данные администраторам для создания учётной записи. После этого новый коммиттер готов сделать свой первый коммит. По традиции, это делается путём добавления своего имени в список коммиттеров.
-Напомним, что коммиттером считается тот, кто за последние 12 месяцев внёс изменения в код. Однако право на коммиты может быть отозвано только после 18 месяцев неактивности.
-Однако не существует автоматических процедур для этого. Для действий, связанных с привилегиями коммитов, не вызванных временем, см. crossref:dev-model[process-reactions,раздел 1.5.8].
+Напомним, что коммиттером считается тот, кто за последние 12 месяцев внёс изменения в код. Однако право на коммиты может быть отозвано только после 18 месяцев неактивности. [crossref:dev-model[freebsd-expiration-policy, "FreeBSD, 2002H"]] Однако, нет автоматической процедуры, чтобы это делать. Что касается действий (реакций) в отношении прав на коммит, которые не инициируются временем, см. crossref:dev-model[process-reactions,раздел 6.7].
.Процесс: удаление коммиттера
image::proc-rm-committer.png["Обратитесь к абзацу ниже для версии, совместимой с программами чтения с экрана."]
-В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [ crossref:dev-model[jorgensen2001, Йоргенсен, 2001]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяется с ветвью -STABLE.
+В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [ crossref:dev-model[jorgensen2001, "Jørgensen, 2001"]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяется с ветвью -STABLE.
Требования проекта определяются пожеланиями разработчиков, запросами сообщества в виде прямых обращений по почте, отчётов о проблемах (Problem Reports), коммерческим финансированием разработки функциональности или вкладами научного сообщества. Пожелания, которые входят в зону ответственности разработчика, передаются этому разработчику, который расставляет приоритеты между запросом и своими собственными пожеланиями. Распространенный способ организации этого процесса — ведение списка задач (TODO-list), поддерживаемого проектом. Задачи, не входящие в чью-либо зону ответственности, собираются в списках TODO, пока кто-нибудь не возьмет на себя ответственность за их выполнение. Все запросы, их распределение и отслеживание обрабатываются с помощью инструмента crossref:dev-model[tool-bugzilla, Bugzilla].
Анализ требований происходит двумя способами. Поступившие запросы обсуждаются в почтовых рассылках, как в основном проекте, так и в подпроекте, к которому относится запрос или который создаётся этим запросом. Кроме того, отдельные разработчики подпроекта оценивают осуществимость запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на этом этапе не создаётся никаких результатов, которые включаются в основной проект.
-Поскольку запросы приоритизируются отдельными разработчиками на основе того, что они считают интересным, необходимым или за что им платят, отсутствует общая стратегия или приоритезация того, какие запросы считать требованиями, и как контролировать их корректную реализацию. Однако большинство разработчиков разделяют общее видение того, какие вопросы являются более важными, и они могут запросить рекомендации у команды инженеров по выпуску релизов.
+Поскольку запросы приоритизируются отдельными разработчиками на основе того, что они считают интересным, необходимым или за что им платят, отсутствует общая стратегия или приоритезация того, какие запросы считать требованиями, и как контролировать их корректную реализацию. Однако большинство разработчиков разделяют общее видение того, какие вопросы являются более важными, и они могут запросить рекомендации у команды подготовки релизов.
Фаза проверки проекта состоит из двух этапов. Перед внесением кода в текущую ветку разработчики запрашивают рецензирование своего кода коллегами. Это рецензирование в основном проводится с помощью функционального тестирования, но также важна проверка кода. Когда код внесён в ветку, проводится более широкое функциональное тестирование, которое может привести к дополнительной проверке кода и отладке, если код ведёт себя не так, как ожидалось. Эта вторая форма проверки может рассматриваться как структурная верификация. Хотя сами подпроекты могут писать формальные тесты, такие как модульные тесты, они обычно не собираются основным проектом и чаще всего удаляются перед внесением кода в текущую ветку. footnote:[Однако всё больше тестов выполняется при сборке системы (make world). Эти тесты являются очень новым дополнением, и систематическая структура для них ещё не создана.]
@@ -660,7 +653,7 @@
Для проекта полезно, чтобы за каждую область исходного кода отвечал хотя бы один человек, который хорошо её знает. Некоторые части кода имеют назначенных сопровождающих. Другие имеют фактических сопровождающих, а некоторые части системы не имеют сопровождающих. Сопровождающий обычно является участником подпроекта, который написал и интегрировал код, или тем, кто портировал его с платформы, для которой он был написан. footnote:[sendmail и named — примеры кода, который был объединён с других платформ.] Задача сопровождающего — убедиться, что код синхронизирован с проектом, из которого он получен, если это сторонний код, а также применять патчи, предоставленные сообществом, или исправлять обнаруженные проблемы.
-Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]] предоставляет схему, показывающую жизненный цикл изменений.
+Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [ crossref:dev-model[jorgensen2001, "Jørgensen, 2001"]] предоставляет схему, показывающую жизненный цикл изменений.
Модель Йоргенссена для интеграции изменений
@@ -673,7 +666,7 @@
|программирование
|рецензирование
-|
+|
|рецензирование
|предварительная проверка перед коммитом
@@ -692,7 +685,7 @@
|программирование
|релиз для производства
-|
+|
|программирование
|===
@@ -714,26 +707,25 @@
Проблема сообщается автором отчёта. Затем она классифицируется ответственным за обработку ошибок и передаётся соответствующему сопровождающему. Он проверяет проблему и обсуждает её с автором отчёта до тех пор, пока не будет собрано достаточно информации для создания рабочего исправления. Это исправление затем фиксируется, и отчёт о проблеме закрывается.
-[ crossref:dev-model[freebsd-committer, FreeBSD, 2001]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
+[ crossref:dev-model[freebsd-committer, "FreeBSD, 2001"]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
* Совершение коммитов во время заморозки кода без одобрения команды Release Engineering — 2 дня
* Коммит изменений в ветку безопасности без одобрения - 2 дня
* Войны коммитов — 5 дней для всех участвующих сторон
Для эффективности приостановок любой член основной команды (Core Team) может применить приостановку до обсуждения на почтовой рассылке "core". Повторные нарушители могут, при 2/3 голосов от основной команды, получить более строгие наказания, включая постоянное лишение прав на коммиты. (Однако последнее всегда рассматривается как крайняя мера из-за присущей ему склонности вызывать споры.) Все приостановки публикуются в почтовой рассылке "developers", доступной только коммиттерам.
@@ -747,9 +739,9 @@
[[process-release-engineering]]
=== Выпуск релизов
-Проект FreeBSD имеет команду инженеров по выпуску релизов с главным инженером, который отвечает за создание релизов FreeBSD для распространения среди пользователей через интернет или продажи в розничных магазинах. Поскольку FreeBSD доступна на нескольких платформах, а релизы для различных архитектур выпускаются одновременно, в команде есть ответственный за каждую архитектуру. Также в команде есть роли, отвечающие за координацию усилий по обеспечению качества, сборку набора пакетов и актуализацию документации. Под инженером по выпуску релизов подразумевается представитель команды инженеров по выпуску релизов.
+Проект FreeBSD имеет команду подготовки релизов с Реководителем команды, который отвечает за создание релизов FreeBSD для распространения среди пользователей через интернет или продажи в розничных магазинах. Поскольку FreeBSD доступна на нескольких платформах, а релизы для различных архитектур выпускаются одновременно, в команде есть ответственный за каждую архитектуру. Также в команде есть роли, отвечающие за координацию усилий по обеспечению качества, сборку набора пакетов и актуализацию документации. Под инженером по выпуску релизов подразумевается представитель команды подготовки релизов.
-Когда готовится выпуск релиза, проект FreeBSD несколько меняет свою структуру. Составляется график выпуска, включающий заморозку функциональности и кода, выпуск промежуточных релизов и финального релиза. Заморозка функциональности означает, что новые функции не могут быть добавлены в ветку без явного согласия инженеров релиза. Заморозка кода означает, что изменения в коде (например, исправления ошибок) не могут быть добавлены без явного согласия инженеров релиза. Этот процесс заморозки функциональности и кода известен как стабилизация. В процессе выпуска релиза инженер релиза имеет полномочия откатываться к более старым версиям кода и, таким образом, "отменять" изменения, если они сочтут, что эти изменения не подходят для включения в релиз.
+Когда готовится выпуск релиза, проект FreeBSD несколько меняет свою структуру. Составляется график выпуска, включающий заморозку функциональности и кода, выпуск промежуточных релизов и финального релиза. Заморозка функциональности означает, что новые функции не могут быть добавлены в ветку без явного согласия инженеров релиза. Заморозка кода означает, что изменения в коде (например, исправления ошибок) не могут быть добавлены без явного согласия инженеров по выпуску релизов. Этот процесс заморозки функциональности и кода известен как стабилизация. В процессе выпуска релиза инженер релиза имеет полномочия откатываться к более старым версиям кода и, таким образом, "отменять" изменения, если они сочтут, что эти изменения не подходят для включения в релиз.
Существует три различных вида выпусков:
@@ -779,7 +771,7 @@
// Keep the spaces around the external square bracket to avoid a warning in the
-Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены для разработки определённых областей интересов, а закрытые рассылки используются для внутренней коммуникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [ crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Приложение C].
+Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены для разработки определённых областей интересов, а закрытые рассылки используются для внутренней коммуникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [crossref:dev-model[ref-bsd-handbook, "FreeBSD, 2003A"], Приложение C].
[[tool-pgp]]
=== Pretty Good Privacy
@@ -834,7 +826,7 @@
С неразветвлённым репозиторием портов невозможно гарантировать, что любой порт будет работать на чём-либо, кроме -CURRENT и -STABLE, в частности на старых, минорных выпусках. Для этого нет ни инфраструктуры, ни времени волонтёров.
-Команды, зависящие от Ports, такие как команда выпуска релизов, для эффективности коммуникации имеют своих собственных представителей по портам.
+Команды, зависящие от Ports, такие как команда подготовки релизов, для эффективности коммуникации имеют своих собственных представителей по портам.
[[sub-project-documentation]]
=== Проект документации FreeBSD
@@ -847,7 +839,7 @@
Как и проект FreeBSD, документация разделена на те же ветви. Это сделано для того, чтобы для каждой версии всегда была обновлённая документация. В ветвях безопасности исправляются только ошибки в документации.
-Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [ crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
+Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [ crossref:dev-model[freebsd-doceng-charter, "FreeBSD, 2003B"]].
Проект документации включает в себя extref:{fdp-primer}[вводное руководство]. Оно используется как для ознакомления новых участников проекта со стандартными инструментами и синтаксисом, так и в качестве справочника при работе над проектом.
msgid "Releng 4 branches: 4.1 Release to 4.6 Release (and 4.6.2 Release), then 4.7 Release to 4.11 Release (all starting at 4.3 Release also leading to a Releng_4_n branch), and the subsequent 4 Release branch"
-msgstr ""
-"Ветви Releng 4: релизы с 4.1 по 4.6 (и релиз 4.6.2), затем релизы с 4.7 по "
-"4.11 (все, начиная с релиза 4.3, также ведущие к ветви Releng_4_n), и "
-"последующая ветвь релиза 4"
+msgstr "Ветви Releng 4: релизы с 4.1 по 4.6 (и релиз 4.6.2), затем релизы с 4.7 по 4.11 (все, начиная с релиза 4.3, также ведущие к ветви Releng_4_n), и последующая ветвь релиза 4"
msgid "Releng 5 branches: 5.0 Release to 5.4 Release (all except 5.0 and 5.3 also leading to a Releng_5_n branch), and the subsequent 5 Release branch"
-msgstr ""
-"Ветви Releng 5: Релизы с 5.0 до 5.4 (за исключением 5.0 и 5.3, которые также "
-"ведут к ветке Releng_5_n), и последующая ветка релиза 5"
+msgstr "Ветви Releng 5: Релизы с 5.0 до 5.4 (за исключением 5.0 и 5.3, которые также ведут к ветке Releng_5_n), и последующая ветка релиза 5"
"*.0 releases go into their own branch and are aimed mainly at early adopters.\n"
"The branch then goes through a period of stabilisation, and it is not until the\n"
"crossref:dev-model[role-releng, Release Engineering Team] decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with *.1 versions, this is not a demand.\n"
msgstr ""
-"*.0 выпуски выделяются в отдельную ветку и ориентированы в основном на "
-"ранних последователей.\n"
+"*.0 выпуски выделяются в отдельную ветку и ориентированы в основном на ранних последователей.\n"
"Затем ветка проходит период стабилизации, и только после того, как\n"
-"crossref:dev-model[role-releng, Команда разработки релизов] решит, что "
-"требования к стабильности выполнены, ветка становится -STABLE, а -CURRENT "
-"переключается на следующую мажорную версию. Хотя в большинстве случаев это "
-"происходило с версиями *.1, это не является обязательным требованием.\n"
+"crossref:dev-model[role-releng, Команда разработки релизов] решит, что требования к стабильности выполнены, ветка становится -STABLE, а -CURRENT переключается на следующую мажорную версию. Хотя в большинстве случаев это происходило с версиями *.1, это не является обязательным требованием.\n"