请登录以查看警报。

概览

项目网站 docs.freebsd.org/en
翻译许可证 BSD 2-Clause "Simplified" License
翻译进程
  • 可以直接翻译。
  • 可以提出翻译建议。
  • 只允许指定的用户贡献。
  • 该翻译使用双语文件。
文件掩码 documentation/content/*/articles/committers-guide/_index.po

字符串统计数据

字符串百分比 托管的字符串数 字数百分比 托管的单词数 字符百分比 托管的字符数
总数 22686 545547 3472326
原文数 1194 28713 182754
已翻译数 18% 4086 16% 91555 16% 585180
需要编辑 5% 1191 6% 34392 6% 217547
只读 5% 1194 5% 28713 5% 182754
未通过的检查数 6% 1394 7% 40542 7% 252838
带有建议的字符串数 1% 3 1% 92 1% 568
未翻译的字符串数 76% 17409 76% 419600 76% 2669599
过去 12 个月 上一年

过去 12 个月内的活动

12 个更改 1223 个更改 48 个更改 501 个更改 1097 个更改 1136 个更改 3 个更改 8174 个更改 714 个更改 65 个更改 0 个更改 24 个更改 3 个更改 856 个更改 404 个更改 2 个更改 1100 个更改 2 个更改 105 个更改 245 个更改 0 个更改 18 个更改 36 个更改 6 个更改
五月 六月 七月 八月 九月 十月 十一月 十二月 一月 二月 三月 四月

快速数字

545 千
托管的单词数
22686
托管的字符串数
18%
已翻译
2
贡献者
及之前 30 天

过去 30 天的趋势

−1%
托管的单词数
+100%
—
托管的字符串数
+100%
—
已翻译
+18%
−50%
贡献者
+100%
用户头像 无

提交了更改

Documentation / articles/committers-guide/_index — 俄语

提交了更改 8 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

Clearly mark direct commits distinct from commits that land a change from another branch.
Чеётко обозначить прямые коммиты, отличая их от коммитов, вносящих изменения из другой ветки.
9 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

Features and compatibility shims used by binaries compiled against older stable branches may be removed in newer major versions. Such removals will be clearly documented in the release notes.
Функции и прослойки совместимости, используемые программами, скомпилированными для старых стабильных веток, могут быть удалены в новых основных версиях. Такие изменения будут чеётко документированы в примечаниях к выпуску.
9 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

FreeBSD is a highly portable operating system intended to function on many different types of hardware architectures. Maintaining clean separation of Machine Dependent (MD) and Machine Independent (MI) code, as well as minimizing MD code, is an important part of our strategy to remain agile with regards to current hardware trends. Each new hardware architecture supported by FreeBSD adds substantially to the cost of code maintenance, toolchain support, and release engineering. It also dramatically increases the cost of effective testing of kernel changes. As such, there is strong motivation to differentiate between classes of support for various architectures while remaining strong in a few key architectures that are seen as the FreeBSD "target audience".
FreeBSD — это высокопортативная операционная система, предназначенная для работы на множестве различных типов аппаратных архитектур. Поддержание чеёткого разделения между машинозависимым (MD) и машинонезависимым (MI) кодом, а также минимизация MD-кода являются важной частью нашей стратегии по сохранению гибкости в отношении текущих тенденций в аппаратном обеспечении. Каждая новая аппаратная архитектура, поддерживаемая FreeBSD, существенно увеличивает затраты на поддержку кода, инструментальных средств и управление выпусками. Это также значительно повышает стоимость эффективного тестирования изменений в ядре. Таким образом, существует серьезная мотивация для разграничения уровней поддержки различных архитектур, оставаясь при этом сильными в нескольких ключевых архитектурах, которые рассматриваются как «целевая аудитория» FreeBSD.
9 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

Historical practice has varied, though some of the variance is by field. For example, MFCs that are relevant to a PR generally include the PR field in the MFC so that MFC commits are included in the bug tracker's audit trail. Other fields are less clear. For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the main commit with the landed commits. The list of reviewers is also not clear. If a reviewer has approved a change to `main`, does that mean they have approved the MFC commit? Is that true if it's identical code only, or with merely trivial rework? It's clearly not true for more extensive reworks. Even for identical code what if the commit doesn't conflict but introduces an ABI change? A reviewer may have ok'd a commit for `main` due to the ABI breakage but may not approve of merging the same commit as-is. One will have to use one's best judgment until clear guidelines can be agreed upon.
Исторически практика различалась, хотя некоторые различия зависят от области. Например, MFC, относящиеся к PR, обычно включают поле PR в MFC, чтобы коммиты MFC включались в аудит-трекер системы отслеживания ошибок. В других областях ситуация менее ясна. Например, Phabricator показывает разницу последнего коммита, помеченного для обзора, поэтому включение URL-адресов Phabricator заменяет основной коммит на завершённые коммиты. Список рецензентов также неясен. Если рецензент одобрил изменение для `main`, означает ли это, что он одобрил коммит MFC? Верно ли это только для идентичного кода или лишь с незначительной доработкой? Очевидно, это неверно для более масштабных доработок. Даже для идентичного кода: что, если коммит не конфликтует, но вносит изменение ABI? Рецензент мог одобрить коммит для `main` из-за нарушения ABI, но может не одобрить слияние того же коммита в неизменном виде. Придется полагаться на собственное наилучшее суждение до тех пор, пока не будут согласованы чеёткие руководящие принципы.
9 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

Historical practice has varied, though some of the variance is by field. For example, MFCs that are relevant to a PR generally include the PR field in the MFC so that MFC commits are included in the bug tracker's audit trail. Other fields are less clear. For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the main commit with the landed commits. The list of reviewers is also not clear. If a reviewer has approved a change to `main`, does that mean they have approved the MFC commit? Is that true if it's identical code only, or with merely trivial rework? It's clearly not true for more extensive reworks. Even for identical code what if the commit doesn't conflict but introduces an ABI change? A reviewer may have ok'd a commit for `main` due to the ABI breakage but may not approve of merging the same commit as-is. One will have to use one's best judgment until clear guidelines can be agreed upon.
Исторически практика различалась, хотя некоторые различия зависят от области. Например, MFC, относящиеся к PR, обычно включают поле PR в MFC, чтобы коммиты MFC включались в аудит-трекер системы отслеживания ошибок. В других областях ситуация менее ясна. Например, Phabricator показывает разницу последнего коммита, помеченного для обзора, поэтому включение URL-адресов Phabricator заменяет основной коммит на завершеённые коммиты. Список рецензентов также неясен. Если рецензент одобрил изменение для `main`, означает ли это, что он одобрил коммит MFC? Верно ли это только для идентичного кода или лишь с незначительной доработкой? Очевидно, это неверно для более масштабных доработок. Даже для идентичного кода: что, если коммит не конфликтует, но вносит изменение ABI? Рецензент мог одобрить коммит для `main` из-за нарушения ABI, но может не одобрить слияние того же коммита в неизменном виде. Придется полагаться на собственное наилучшее суждение до тех пор, пока не будут согласованы четкие руководящие принципы.
9 天前
用户头像 v.popolitov

搜索并替换

Documentation / articles/committers-guide/_index — 俄语

Changes merged to stable branches cannot break the protected portions of the kernel ABI. If a kernel ABI change is required, the change should be modified to preserve functionality of existing kernel modules.
Изменения, которым сделано слияние в стабильные ветки, не должны нарушать защищеённые части ABI ядра. Если требуется изменение ABI ядра, изменение должно быть модифицировано для сохранения функциональности существующих модулей ядра.
9 天前
用户头像 无

提交了更改

Documentation / articles/committers-guide/_index — 俄语

提交了更改 2 周前
用户头像 v.popolitov

修改了译文

Documentation / articles/committers-guide/_index — 俄语

/*
* Copyright (c) [year] [your name]
*
* SPDX-License-Identifier: BSD-2-Clause
*
*/
/*
* Copyright (c) [year] [your name]
*
* SPDX-License-Identifier: BSD-2-Clause
*
*/
2 周前
用户头像 v.popolitov

标记为需要编辑

Documentation / articles/committers-guide/_index — 俄语

/*
* Copyright (c) [year] [your name]
*
* SPDX-License-Identifier: BSD-2-Clause
*
*/
/*
* Copyright (c) [year] [your name]
*
* SPDX-License-Identifier: BSD-2-Clause
*
*/
2 周前
浏览部件的所有变化