Page MenuHomeFreeBSD
Files F161616392

D56937.diff
No OneTemporary
Actions

D56937.diff
View Options

diff --git a/documentation/content/ru/books/dev-model/_index.adoc b/documentation/content/ru/books/dev-model/_index.adoc
--- a/documentation/content/ru/books/dev-model/_index.adoc
+++ b/documentation/content/ru/books/dev-model/_index.adoc
@@ -325,7 +325,7 @@
«Основной выпуск» всегда создаётся из ветки -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 @@
Требования проекта определяются пожеланиями разработчиков, запросами сообщества в виде прямых обращений по почте, отчётов о проблемах (Problem Reports), коммерческим финансированием разработки функциональности или вкладами научного сообщества. Пожелания, которые входят в зону ответственности разработчика, передаются этому разработчику, который расставляет приоритеты между запросом и своими собственными пожеланиями. Распространенный способ организации этого процесса — ведение списка задач (TODO-list), поддерживаемого проектом. Задачи, не входящие в чью-либо зону ответственности, собираются в списках TODO, пока кто-нибудь не возьмет на себя ответственность за их выполнение. Все запросы, их распределение и отслеживание обрабатываются с помощью инструмента crossref:dev-model[tool-bugzilla, Bugzilla].
-Анализ требований происходит двумя способами. Поступившие запросы обсуждаются в почтовых рассылках, как в основном проекте, так и в подпроекте, к которому относится запрос или который создается этим запросом. Кроме того, отдельные разработчики подпроекта оценивают осуществимость запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на этом этапе не создается никаких результатов, которые включаются в основной проект.
+Анализ требований происходит двумя способами. Поступившие запросы обсуждаются в почтовых рассылках, как в основном проекте, так и в подпроекте, к которому относится запрос или который создаётся этим запросом. Кроме того, отдельные разработчики подпроекта оценивают осуществимость запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на этом этапе не создаётся никаких результатов, которые включаются в основной проект.
Поскольку запросы приоритизируются отдельными разработчиками на основе того, что они считают интересным, необходимым или за что им платят, отсутствует общая стратегия или приоритезация того, какие запросы считать требованиями, и как контролировать их корректную реализацию. Однако большинство разработчиков разделяют общее видение того, какие вопросы являются более важными, и они могут запросить рекомендации у команды инженеров по выпуску релизов.
@@ -699,7 +699,7 @@
Здесь "релиз для разработки" относится к ветке -CURRENT, а "релиз для производства" — к ветке -STABLE. "Предварительная проверка перед коммитом" — это функциональное тестирование, проводимое коллегами-разработчиками по запросу или для проверки кода с целью определения состояния подпроекта. "Параллельная отладка" — это функциональное тестирование, которое может вызвать дополнительный обзор и отладку, когда код включён в ветку -CURRENT.
-На момент написания этого документа в проекте было 269 коммиттеров. Когда они вносят изменения в ветку, это создает новый выпуск. Очень часто пользователи в сообществе отслеживают определённую ветку. Мгновенное появление нового выпуска делает изменения широко доступными сразу же и позволяет быстро получать отзывы от сообщества. Это также даёт сообществу ожидаемое время реакции на проблемы, которые важны для них. Это делает сообщество более вовлеченным, что, в свою очередь, позволяет получать больше и лучше отзывов, что снова стимулирует больше сопровождения и в конечном итоге должно создать лучший продукт.
+На момент написания этого документа в проекте было 269 коммиттеров. Когда они вносят изменения в ветку, это создаёт новый выпуск. Очень часто пользователи в сообществе отслеживают определённую ветку. Мгновенное появление нового выпуска делает изменения широко доступными сразу же и позволяет быстро получать отзывы от сообщества. Это также даёт сообществу ожидаемое время реакции на проблемы, которые важны для них. Это делает сообщество более вовлеченным, что, в свою очередь, позволяет получать больше и лучше отзывов, что снова стимулирует больше сопровождения и в конечном итоге должно создать лучший продукт.
Прежде чем вносить изменения в код в частях дерева, история которых неизвестна коммиттеру, коммиттер обязан прочитать журналы коммитов, чтобы понять, почему определённые функции реализованы именно так, и избежать ошибок, которые уже были обдуманы или исправлены ранее.
@@ -758,7 +758,7 @@
. .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, заморозка кода релиз-кандидата ужесточается. Однако разработка на основной ветке разработки может продолжаться. За исключением этих различий, процессы разработки релизов схожи.
diff --git a/documentation/content/ru/books/dev-model/_index.po b/documentation/content/ru/books/dev-model/_index.po
--- a/documentation/content/ru/books/dev-model/_index.po
+++ b/documentation/content/ru/books/dev-model/_index.po
@@ -6,7 +6,7 @@
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 @@
"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 @@
msgstr ""
"Анализ требований происходит двумя способами. Поступившие запросы "
"обсуждаются в почтовых рассылках, как в основном проекте, так и в "
-"подпроекте, к которому относится запрос или который создается этим запросом. "
+"подпроекте, к которому относится запрос или который создаётся этим запросом. "
"Кроме того, отдельные разработчики подпроекта оценивают осуществимость "
"запросов и определяют приоритеты между ними. Помимо архивов обсуждений, на "
-"этом этапе не создается никаких результатов, которые включаются в основной "
+"этом этапе не создаётся никаких результатов, которые включаются в основной "
"проект."
#. type: Plain text
@@ -2797,7 +2797,7 @@
"ultimately should create a better product."
msgstr ""
"На момент написания этого документа в проекте было 269 коммиттеров. Когда "
-"они вносят изменения в ветку, это создает новый выпуск. Очень часто "
+"они вносят изменения в ветку, это создаёт новый выпуск. Очень часто "
"пользователи в сообществе отслеживают определённую ветку. Мгновенное "
"появление нового выпуска делает изменения широко доступными сразу же и "
"позволяет быстро получать отзывы от сообщества. Это также даёт сообществу "
@@ -3130,11 +3130,11 @@
"обновления документации, исправления, связанные с безопасностью, и "
"незначительные изменения драйверов устройств. Эти изменения должны быть "
"предварительно одобрены инженером выпуска. В начале последнего 15-дневного "
-"периода создается кандидат на выпуск для широкого тестирования. В этот "
+"периода создаётся кандидат на выпуск для широкого тестирования. В этот "
"период вероятность внесения изменений снижается, за исключением важных "
"исправлений ошибок и обновлений безопасности. В этот заключительный период "
"все выпуски считаются кандидатами на выпуск. По завершении процесса выпуска "
-"создается релиз с новым номером версии, включая бинарные дистрибутивы на веб-"
+"создаётся релиз с новым номером версии, включая бинарные дистрибутивы на веб-"
"сайтах и создание образов CD-ROM. Однако релиз не считается «действительно "
"выпущенным» до тех пор, пока на список рассылки freebsd-announce не будет "
"отправлено сообщение, подписанное с помощью crossref:dev-model[tool-pgp, "

File Metadata

Mime Type
text/plain
Expires
Mon, Jul 6, 8:22 AM (4 h, 1 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
34746937
Default Alt Text
D56937.diff (22 KB)

Event Timeline