From nobody Sun May 17 18:19:35 2026 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gJTjg1Vkwz6cljp for ; Sun, 17 May 2026 18:19:35 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gJTjg15zrz49qR for ; Sun, 17 May 2026 18:19:35 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1779041975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=QuymW9NFWPLxqUzzfQ2lBA0WMn43sg/oMPWTCZHTzUQ=; b=KyyT7DK+NL95lka/mwLDd4mzPCvRygAcl+KdpgYeN83z+2CRABT1emZwRNuAglwEL4b4DE gkN8LEFyat1ijo71AzHy/+jkV48nO3IUUhqOFq4JNEOJDReWopkW1vh/igDapyrerGUvew 1Xb6vlmOIOxrAJ2vmG02dE+7M5btQbcfM17+pck5Grr4RvgeG+D+Pt0Y9jPbIytUcAIpsm HW4yD0+o8qtsBMjQs1AkOmImYtw7fdr2pQ+8a5Ck/HfJEQBGxOavSvpg9PSOZzRblPt30L kf7qOAFL/udsFTHGmZTovurbkyP65Y8vjisQJlcUfJApsJNl6I1mk4+DFxlHow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1779041975; a=rsa-sha256; cv=none; b=fj74Uh3RkTbuR+NJwf3jfOTK2mT6tkPPYbzUKxIhHIX1zg2QCECj+MXzNa/FzaFTRPzCdI ddtteBZPCn5VTvf4FN7Xv6E/5uYq+pPcdGZIqAVIPQNSp14e1+clw9yQcUs2ZMTm3XrOIE JmJ6ByMFo84aCgIIluKVXrb3L5KkAKNVQy7Zrgu+UPzMbMUdiCM8+jI6nhoGt0nJob9aib hp4+wb4atNPNBPLNpaWElIk9u2S2Fl9mEonKCM+J1f4xvhy86ab6E28hNfodktjqpcLKaS 1MVXRrTzrqcXogmRVaih/wQBab2nekpLBlDCOduLCLE4ES9NMo5pCbQEgtXfhw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1779041975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=QuymW9NFWPLxqUzzfQ2lBA0WMn43sg/oMPWTCZHTzUQ=; b=CvO6bPYGnzPPAtGByc1Fm4fWl9P8X09Vm9VcOTqtqN4wVUrbOa1JicL9X7ModU7NRDRcXn 8Frp0KK6iBySC5Nvo8o5+vyn9jAAIh1Op5Qi36amH/75k81Yncp/m4vXFSOb1Ez4hGR9iM CvtER8zVNq6s9iunYaXUpfJws9ZA9aGacieCIivdVl4bqwmySvQnc5JKnSJBhuVUeZS9SH ryHcTwFrAU9voU5tx5KdwJJW+4+3ifcWSV5EE2DuBeJt5uFjdiSKIplOTjgkzyGwpXPCQi Ez6hBxzXUpZGr3yNYEdD8yjJ3AOJyLrN2BFcDJ663o8D+7hMpTu3U+ojfZ2t/g== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id 4gJTjg0d9vzsnf for ; Sun, 17 May 2026 18:19:35 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from git (uid 1279) (envelope-from git@FreeBSD.org) id 231f3 by gitrepo.freebsd.org (DragonFly Mail Agent v0.13+ on gitrepo.freebsd.org); Sun, 17 May 2026 18:19:35 +0000 To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Vladlen Popolitov Subject: git: 3b29d2e69b - main - update translation of books/dev-model to Russian List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-doc-all@freebsd.org Sender: owner-dev-commits-doc-all@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: vladlen X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 3b29d2e69b8221b65c589792db00ec318426f4f8 Auto-Submitted: auto-generated Date: Sun, 17 May 2026 18:19:35 +0000 Message-Id: <6a0a06b7.231f3.68a5016b@gitrepo.freebsd.org> The branch main has been updated by vladlen: URL: https://cgit.FreeBSD.org/doc/commit/?id=3b29d2e69b8221b65c589792db00ec318426f4f8 commit 3b29d2e69b8221b65c589792db00ec318426f4f8 Author: Vladlen Popolitov AuthorDate: 2026-05-17 18:19:26 +0000 Commit: Vladlen Popolitov 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 \n" "Language-Team: Russian \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, "