Date: Sun, 17 May 2026 18:19:35 +0000 From: Vladlen Popolitov <vladlen@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: 3b29d2e69b - main - update translation of books/dev-model to Russian Message-ID: <6a0a06b7.231f3.68a5016b@gitrepo.freebsd.org>
index | next in thread | raw e-mail
The branch main has been updated by vladlen: URL: https://cgit.FreeBSD.org/doc/commit/?id=3b29d2e69b8221b65c589792db00ec318426f4f8 commit 3b29d2e69b8221b65c589792db00ec318426f4f8 Author: Vladlen Popolitov <vladlen@FreeBSD.org> AuthorDate: 2026-05-17 18:19:26 +0000 Commit: Vladlen Popolitov <vladlen@FreeBSD.org> CommitDate: 2026-05-17 18:19:26 +0000 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 | 8 ++++---- documentation/content/ru/books/dev-model/_index.po | 14 +++++++------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/documentation/content/ru/books/dev-model/_index.adoc b/documentation/content/ru/books/dev-model/_index.adoc index ccc148b7b6..d6f08d28e7 100644 --- a/documentation/content/ru/books/dev-model/_index.adoc +++ b/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, заморозка кода релиз-кандидата ужесточается. Однако разработка на основной ветке разработки может продолжаться. За исключением этих различий, процессы разработки релизов схожи. diff --git a/documentation/content/ru/books/dev-model/_index.po b/documentation/content/ru/books/dev-model/_index.po index c9fe03a444..89d8a79143 100644 --- a/documentation/content/ru/books/dev-model/_index.po +++ b/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, "home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a0a06b7.231f3.68a5016b>