update translation of books/dev-model to Russian

Reviewed by: andy
Differential Revision: https://reviews.freebsd.org/В56937

documentation/content/ru/books/dev-model/_index.adoc

@@ -325,7 +325,7 @@ image::branches.png["Обратитесь к таблице ниже для уд
 
 «Основной выпуск» всегда создаётся из ветки -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.
 
-"Минорный релиз" создается из ветки -CURRENT после основного релиза или из ветки -STABLE.
+"Минорный релиз" создаётся из ветки -CURRENT после основного релиза или из ветки -STABLE.
 
 Начиная с версии 4.3-RELEASE footnote:[Первым релизом, для которого это действительно произошло, был 4.5-RELEASE, но ветки безопасности были созданы одновременно для 4.3-RELEASE и 4.4-RELEASE.], когда выпускается минорный релиз, он становится «веткой безопасности». Это предназначено для организаций, которые не хотят следовать ветке -STABLE и потенциальным новым/изменённым функциям, которые она предлагает, но вместо этого требуют абсолютно стабильной среды, обновляемой только для внедрения исправлений безопасности. footnote:[Здесь вы видите терминологическое пересечение со словом «стабильный», что приводит к некоторой путанице. Ветка -STABLE по-прежнему является веткой разработки, цель которой — быть полезной для большинства пользователей. Если для системы неприемлемо получать изменения, которые не были объявлены на момент её развёртывания, такая система должна работать на ветке безопасности.]
 
@@ -650,7 +650,7 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 
 Требования проекта определяются пожеланиями разработчиков, запросами сообщества в виде прямых обращений по почте, отчётов о проблемах (Problem Reports), коммерческим финансированием разработки функциональности или вкладами научного сообщества. Пожелания, которые входят в зону ответственности разработчика, передаются этому разработчику, который расставляет приоритеты между запросом и своими собственными пожеланиями. Распространенный способ организации этого процесса — ведение списка задач (TODO-list), поддерживаемого проектом. Задачи, не входящие в чью-либо зону ответственности, собираются в списках TODO, пока кто-нибудь не возьмет на себя ответственность за их выполнение. Все запросы, их распределение и отслеживание обрабатываются с помощью инструмента crossref:dev-model[tool-bugzilla, Bugzilla].
 
-Анализ требований происходит двумя способами. Поступившие запросы обсуждаются в почтовых рассылках, как в основном проекте, так и в подпроекте, к которому относится запрос или который создается этим запросом. Кроме того, отдельные разработчики подпроекта оценивают осуществимость запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на этом этапе не создается никаких результатов, которые включаются в основной проект.
+Анализ требований происходит двумя способами. Поступившие запросы обсуждаются в почтовых рассылках, как в основном проекте, так и в подпроекте, к которому относится запрос или который создаётся этим запросом. Кроме того, отдельные разработчики подпроекта оценивают осуществимость запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на этом этапе не создаётся никаких результатов, которые включаются в основной проект.
 
 Поскольку запросы приоритизируются отдельными разработчиками на основе того, что они считают интересным, необходимым или за что им платят, отсутствует общая стратегия или приоритезация того, какие запросы считать требованиями, и как контролировать их корректную реализацию. Однако большинство разработчиков разделяют общее видение того, какие вопросы являются более важными, и они могут запросить рекомендации у команды инженеров по выпуску релизов.
 
@@ -699,7 +699,7 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 
 Здесь "релиз для разработки" относится к ветке -CURRENT, а "релиз для производства" — к ветке -STABLE. "Предварительная проверка перед коммитом" — это функциональное тестирование, проводимое коллегами-разработчиками по запросу или для проверки кода с целью определения состояния подпроекта. "Параллельная отладка" — это функциональное тестирование, которое может вызвать дополнительный обзор и отладку, когда код включён в ветку -CURRENT.
 
-На момент написания этого документа в проекте было 269 коммиттеров. Когда они вносят изменения в ветку, это создает новый выпуск. Очень часто пользователи в сообществе отслеживают определённую ветку. Мгновенное появление нового выпуска делает изменения широко доступными сразу же и позволяет быстро получать отзывы от сообщества. Это также даёт сообществу ожидаемое время реакции на проблемы, которые важны для них. Это делает сообщество более вовлеченным, что, в свою очередь, позволяет получать больше и лучше отзывов, что снова стимулирует больше сопровождения и в конечном итоге должно создать лучший продукт.
+На момент написания этого документа в проекте было 269 коммиттеров. Когда они вносят изменения в ветку, это создаёт новый выпуск. Очень часто пользователи в сообществе отслеживают определённую ветку. Мгновенное появление нового выпуска делает изменения широко доступными сразу же и позволяет быстро получать отзывы от сообщества. Это также даёт сообществу ожидаемое время реакции на проблемы, которые важны для них. Это делает сообщество более вовлеченным, что, в свою очередь, позволяет получать больше и лучше отзывов, что снова стимулирует больше сопровождения и в конечном итоге должно создать лучший продукт.
 
 Прежде чем вносить изменения в код в частях дерева, история которых неизвестна коммиттеру, коммиттер обязан прочитать журналы коммитов, чтобы понять, почему определённые функции реализованы именно так, и избежать ошибок, которые уже были обдуманы или исправлены ранее.
 
@@ -758,7 +758,7 @@ image::proc-pr.png["Обратитесь к абзацу ниже для вер
 . .X релизы — это релизы ветки -STABLE. Они запланированы к выходу каждые 4 месяца.
 . .X.Y — это выпуски с исправлениями уязвимостей, следующие за веткой .X. Они выходят только тогда, когда с момента последнего выпуска в этой ветке было объединено достаточное количество исправлений уязвимостей. Новые функции включаются редко, а команда безопасности участвует в этих выпусках гораздо активнее, чем в обычных.
 
-Для выпусков ветки -STABLE процесс выпуска начинается за 45 дней до предполагаемой даты релиза. В течение первой фазы, первых 15 дней, разработчики переносят изменения из -CURRENT, которые они хотят включить в релиз, в ветку выпуска. По окончании этого периода код входит в 15-дневный период заморозки, в течение которого допускаются только исправления ошибок, обновления документации, исправления, связанные с безопасностью, и незначительные изменения драйверов устройств. Эти изменения должны быть предварительно одобрены инженером выпуска. В начале последнего 15-дневного периода создается кандидат на выпуск для широкого тестирования. В этот период вероятность внесения изменений снижается, за исключением важных исправлений ошибок и обновлений безопасности. В этот заключительный период все выпуски считаются кандидатами на выпуск. По завершении процесса выпуска создается релиз с новым номером версии, включая бинарные дистрибутивы на веб-сайтах и создание образов CD-ROM. Однако релиз не считается «действительно выпущенным» до тех пор, пока на список рассылки freebsd-announce не будет отправлено сообщение, подписанное с помощью crossref:dev-model[tool-pgp, Pretty Good Privacy], в котором явно указано, что релиз состоялся; все, что обозначено как «релиз» до этого момента, может находиться в процессе доработки и изменяться до отправки PGP-подписанного сообщения. footnote:[Многие коммерческие поставщики используют эти образы для создания CD-ROM, которые продаются в розничных магазинах.].
+Для выпусков ветки -STABLE процесс выпуска начинается за 45 дней до предполагаемой даты релиза. В течение первой фазы, первых 15 дней, разработчики переносят изменения из -CURRENT, которые они хотят включить в релиз, в ветку выпуска. По окончании этого периода код входит в 15-дневный период заморозки, в течение которого допускаются только исправления ошибок, обновления документации, исправления, связанные с безопасностью, и незначительные изменения драйверов устройств. Эти изменения должны быть предварительно одобрены инженером выпуска. В начале последнего 15-дневного периода создаётся кандидат на выпуск для широкого тестирования. В этот период вероятность внесения изменений снижается, за исключением важных исправлений ошибок и обновлений безопасности. В этот заключительный период все выпуски считаются кандидатами на выпуск. По завершении процесса выпуска создаётся релиз с новым номером версии, включая бинарные дистрибутивы на веб-сайтах и создание образов CD-ROM. Однако релиз не считается «действительно выпущенным» до тех пор, пока на список рассылки freebsd-announce не будет отправлено сообщение, подписанное с помощью crossref:dev-model[tool-pgp, Pretty Good Privacy], в котором явно указано, что релиз состоялся; все, что обозначено как «релиз» до этого момента, может находиться в процессе доработки и изменяться до отправки PGP-подписанного сообщения. footnote:[Многие коммерческие поставщики используют эти образы для создания CD-ROM, которые продаются в розничных магазинах.].
 
 Версии ветки -CURRENT (то есть все версии, оканчивающиеся на ".0"), очень похожи, но с вдвое большим временным промежутком. Процесс начинается за 8 недель до выпуска с объявления графика релиза. Через две недели после начала процесса выпуска вводится заморозка функциональности, и оптимизация производительности должна быть сведена к минимуму. За четыре недели до выпуска становится доступна официальная бета-версия. За две недели до выпуска код официально ветвится в новую версию. Этой версии присваивается статус релиз-кандидата, и, как и в случае с разработкой -STABLE, заморозка кода релиз-кандидата ужесточается. Однако разработка на основной ветке разработки может продолжаться. За исключением этих различий, процессы разработки релизов схожи.
 

documentation/content/ru/books/dev-model/_index.po

@@ -6,7 +6,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: FreeBSD Documentation VERSION\n"
 "POT-Creation-Date: 2025-05-01 19:56-0300\n"
-"PO-Revision-Date: 2026-03-05 04:45+0000\n"
+"PO-Revision-Date: 2026-04-05 04:45+0000\n"
 "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
 "Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
 "documentation/booksdev-model_index/ru/>\n"
@@ -1179,7 +1179,7 @@ msgid ""
 "A \"minor release\" is made from the -CURRENT branch following a major "
 "release, or from the -STABLE branch."
 msgstr ""
-"\"Минорный релиз\" создается из ветки -CURRENT после основного релиза или из "
+"\"Минорный релиз\" создаётся из ветки -CURRENT после основного релиза или из "
 "ветки -STABLE."
 
 #. type: Plain text
@@ -2670,10 +2670,10 @@ msgid ""
 msgstr ""
 "Анализ требований происходит двумя способами. Поступившие запросы "
 "обсуждаются в почтовых рассылках, как в основном проекте, так и в "
-"подпроекте, к которому относится запрос или который создается этим запросом. "
+"подпроекте, к которому относится запрос или который создаётся этим запросом. "
 "Кроме того, отдельные разработчики подпроекта оценивают осуществимость "
 "запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на "
-"этом этапе не создается никаких результатов, которые включаются в основной "
+"этом этапе не создаётся никаких результатов, которые включаются в основной "
 "проект."
 
 #. type: Plain text
@@ -2797,7 +2797,7 @@ msgid ""
 "ultimately should create a better product."
 msgstr ""
 "На момент написания этого документа в проекте было 269 коммиттеров. Когда "
-"они вносят изменения в ветку, это создает новый выпуск. Очень часто "
+"они вносят изменения в ветку, это создаёт новый выпуск. Очень часто "
 "пользователи в сообществе отслеживают определённую ветку. Мгновенное "
 "появление нового выпуска делает изменения широко доступными сразу же и "
 "позволяет быстро получать отзывы от сообщества. Это также даёт сообществу "
@@ -3130,11 +3130,11 @@ msgstr ""
 "обновления документации, исправления, связанные с безопасностью, и "
 "незначительные изменения драйверов устройств. Эти изменения должны быть "
 "предварительно одобрены инженером выпуска. В начале последнего 15-дневного "
-"периода создается кандидат на выпуск для широкого тестирования. В этот "
+"периода создаётся кандидат на выпуск для широкого тестирования. В этот "
 "период вероятность внесения изменений снижается, за исключением важных "
 "исправлений ошибок и обновлений безопасности. В этот заключительный период "
 "все выпуски считаются кандидатами на выпуск. По завершении процесса выпуска "
-"создается релиз с новым номером версии, включая бинарные дистрибутивы на веб-"
+"создаётся релиз с новым номером версии, включая бинарные дистрибутивы на веб-"
 "сайтах и создание образов CD-ROM. Однако релиз не считается «действительно "
 "выпущенным» до тех пор, пока на список рассылки freebsd-announce не будет "
 "отправлено сообщение, подписанное с помощью crossref:dev-model[tool-pgp, "