git: cf5e9c58a9 - main - update translation of articles/committers-guide to Russian

The branch main has been updated by vladlen:

URL: https://cgit.FreeBSD.org/doc/commit/?id=cf5e9c58a92907aa55ec267f19f14bba2215c020

commit cf5e9c58a92907aa55ec267f19f14bba2215c020
Author:     Vladlen Popolitov <[email protected]>
AuthorDate: 2025-09-18 18:52:04 +0000
Commit:     Vladlen Popolitov <[email protected]>
CommitDate: 2025-09-18 18:52:53 +0000

    update translation of articles/committers-guide to Russian
    
    Reviewed by: maxim (mentor)
    Approved by: maxim (mentor)
    Differential Revision: https://reviews.freebsd.org/D52505
---
 .../ru/articles/committers-guide/_index.adoc       |  3644 ++++--
 .../content/ru/articles/committers-guide/_index.po | 12213 +++++++++++++++++++
 2 files changed, 15026 insertions(+), 831 deletions(-)

diff --git a/documentation/content/ru/articles/committers-guide/_index.adoc b/documentation/content/ru/articles/committers-guide/_index.adoc
index 96448dfda8..fdc0635660 100644
--- a/documentation/content/ru/articles/committers-guide/_index.adoc
+++ b/documentation/content/ru/articles/committers-guide/_index.adoc
@@ -1,13 +1,16 @@
 ---
-title: Справочник коммиттера
 authors:
-  - author: The FreeBSD Documentation Project
-  - author: Дмитрий Морозовский
-copyright: 1999-2007 The FreeBSD Documentation Project
-trademarks: ["freebsd", "cvsup", "ibm", "intel", "sparc", "general"]
+  - 
+    author: 'The FreeBSD Documentation Project'
+copyright: '1999-2022 The FreeBSD Documentation Project'
+description: 'Вводная информация для коммиттеров FreeBSD'
+tags: "[\"FreeBSD Committer's Guide\", \"Guide\", \"Community\"]"
+title: 'Руководство коммиттера'
+trademarks: ["freebsd", "coverity", "git", "github", "gitlab", "ibm", "intel", "general"]
+weight: 25
 ---
 
-= Справочник коммиттера
+= Руководство коммиттера
 :doctype: article
 :toc: macro
 :toclevels: 1
@@ -41,7 +44,11 @@ endif::[]
 [.abstract-title]
 Аннотация
 
-Данный документ содержит информацию для сообщества коммиттеров FreeBSD. Все новые коммиттеры должны изучить его перед началом работы; прочим коммиттерам также рекомендуется время от времени просматривать его.
+В этом документе представлена информация для сообщества коммиттеров FreeBSD. Все новые коммиттеры должны прочитать этот документ перед началом работы, а существующим коммиттерам настоятельно рекомендуется периодически его пересматривать.
+
+Почти все разработчики FreeBSD имеют права на коммит в один или несколько репозиториев. Однако некоторые разработчики не имеют таких прав, и часть информации здесь применима и к ним. (Например, некоторые люди имеют права только для работы с базой данных отчетов о проблемах.) Дополнительную информацию можно найти в crossref:committers-guide[non-committers, Вопросы, специфичные для разработчиков без прав на коммит].
+
+Этот документ также может быть интересен участникам сообщества FreeBSD, которые хотят узнать больше о том, как работает проект.
 
 '''
 
@@ -51,1107 +58,3082 @@ toc::[]
 == Административные детали
 
 [.informaltable]
-[cols="20%,80%", frame="none"]
+[cols="1,1", frame="none"]
 |===
 
-|__Хост основного репозитория__
-|`ncvs.FreeBSD.org`
+|_Способ логина_
+|man:ssh[1], только протокол версии 2
 
-|__Способ авторизации__
-|man:ssh[1], только протокол 2
+|_Главный хост для входа в оболочку_
+|`freefall.FreeBSD.org`
 
-|__Основной корень репозитория (CVSROOT)__
-|`ncvs.FreeBSD.org`: [.filename]#/home/ncvs# (см. также <<cvs.operations>>). 
+|_Референсные машины_
+|`ref*.FreeBSD.org`, `universe*.freeBSD.org` (см. также ссылку link:https://www.FreeBSD.org/internal/machines/[Хосты проекта FreeBSD])
 
-|__`{cvsadm}`__
-|`{peter}` и `{markm}`, а также `{joe}` и `{marcus}` для иерархии [.filename]#ports/#
+|_Узел SMTP_
+|`smtp.FreeBSD.org:587` (см. также crossref:committers-guide[smtp-setup, Настройка доступа SMTP]).
 
-|__Списки рассылки__
-|{doc-developers-name}, {doc-committers-name}; {ports-developers-name}, {ports-committers-name}; {src-developers-name}, {src-committers-name}. (Каждому репозиторию проекта соответствуют отдельные списки рассылки с суффиксами -developers и -committers. Архивы этих списков хранятся в файлах [.filename]#/home/mail/repository-name-developers-archive# и [.filename]#/home/mail/repository-name-committers-archive# на машинах кластера `FreeBSD.org`). 
+|`_src/_` Git-репозиторий
+|`ssh://[email protected]/src.git`
 
-|__Отчеты Правления__
-|[.filename]#/home/core/public/monthly-report# на машинах кластера `FreeBSD.org`. 
+|`_doc/_` Git-репозиторий
+|`ssh://[email protected]/doc.git`
 
-|__Наиболее значимые метки CVS__
-|`RELENG_4` (ветвь 4.X-STABLE), `RELENG_5` (ветвь 5.X-STABLE), `RELENG_6` (ветвь 6.X-STABLE), `HEAD` (ветвь -CURRENT)
-|===
+|`_ports/_` Git-репозиторий
+|`ssh://[email protected]/ports.git`
 
-Для авторизации на машины проекта вы должны использовать протоколы man:ssh[1] или man:telnet[1] с включенным Kerberos 5. В случае man:ssh[1], допустим только протокол версии 2. Эти протоколы являются значительно более защищенными по сравнению с man:telnet[1] или man:rlogin[1], поскольку информация об авторизации передается в зашифрованном виде. По умолчанию, протокол man:ssh[1] также шифрует весь трафик. Учитывая наличие таких утилит, как man:ssh-agent[1] и man:scp[1], протокол man:ssh[
 1] значительно удобнее прочих в использовании. Если вы ничего не знаете об man:ssh[1], загляните в раздел <<ssh.guide>>.
+|_Внутренние списки рассылки_
+|developers (технически называемый all-developers), doc-developers, doc-committers, ports-developers, ports-committers, src-developers, src-committers. (Каждый репозиторий проекта имеет свои собственные списки рассылки -developers и -committers. Архивы этих списков можно найти в файлах [.filename]#/local/mail/repository-name-developers-archive# и [.filename]#/local/mail/repository-name-committers-archive# на `freefall.FreeBSD.org`.)
 
-[[committer.types]]
-== Типы коммит битов
+|_Ежемесячные отчеты основной команды (Core Team)_
+|[.filename]#/home/core/public/reports# на кластере `FreeBSD.org`.
 
-CVS Репозиторий FreeBSD состоит из нескольких разделов, охватывающих исходные тексты базовой операционной системы, документацию, инфраструктуру построения внешних приложений (портов), а также различные служебные утилиты. Право записи в репозиторий ("коммит бит") подразумевает указание области дерева, в которое оно может быть применено. Как правило, области напрямую связаны с группой, подтвердившей право коммиттера на бит. В дальнейшем, 
 область действия коммит бита может быть расширена; в этом случае, коммиттер должен следовать стандартным пр
 авилам нового для коммиттера в данной области, в частности, получая подтверждения на каждый коммит и, возможно, в течение какого-то времени работу с ментором.
+|_Ежемесячные отчеты команды управления портами_
+|[.filename]#/home/portmgr/public/monthly-reports# в кластере `FreeBSD.org`.
 
-[.informaltable]
-[cols="1,1,1", frame="none"]
+|_Важные ветки Git в `src/`:_
+|`stable/n` (`n`-STABLE), `main` (-CURRENT)
 |===
 
-|__Тип коммит бита__
-|__Ответственные__
-|__Области репозитория__
+Для подключения к хостам проекта требуется man:ssh[1]. Дополнительную информацию
+можно найти в crossref:committers-guide[ssh.guide, Руководстве по быстрому началу работы с SSH].
 
-|src
-|core@
-|src/ и соответствующие части doc/
+Полезные ссылки:
 
-|doc
-|doceng@
-|doc/, www/, документация дерева src/
+* link:https://www.FreeBSD.org/internal/[Внутренние страницы проекта FreeBSD]
+* link:https://www.FreeBSD.org/internal/machines/[Узлы проекта FreeBSD]
+* link:https://www.FreeBSD.org/administration/[Административные группы проекта FreeBSD]
 
-|ports
-|portmgr@
-|ports/
-|===
+[[pgpkeys]]
+== Ключи OpenPGP для FreeBSD
+
+Криптографические ключи, соответствующие стандарту OpenPGP (__Pretty Good Privacy__), используются проектом FreeBSD для аутентификации коммиттеров. Сообщения, содержащие важную информацию, такие как публичные SSH-ключи, могут быть подписаны с помощью OpenPGP-ключа, чтобы доказать, что они действительно отправлены коммиттером. Дополнительную информацию можно найти в https://nostarch.com/releases/pgp_release.pdf[PGP & GPG: Email for the Practical Paranoid от Michael Lucas] и https://en.wikipedia.org/wiki/Pretty_Good_Privac
 y[].
 
-Биты, выделенные до разделения дерева на области могут использоваться во всех частях дерева. Однако, с точки зрения здравого смысла, коммиттер, не имеющий опыта работы в какой-либо части дерева, должен предоставлять предлагаемые изменения для рассмотрения другими коммиттерами, получать подтверждения от ответственных за различные части репозитория, а также, возможно, работать совместно с ментором. Поскольку правила ведения различÐ
 ½Ñ‹Ñ… областей кода различаются, указанные нормы скорее направлены на благо коммиттера, не имеющего достаточн
 ого опыта работы в данной области.
+[[pgpkeys-creating]]
+=== Создание ключа
 
-Вне зависимости от области приложения усилий, запросы коммиттеров на рассмотрение предлагаемых изменений в процессе разработки могут только приветствоваться.
+Существующие ключи можно использовать, но сначала их следует проверить с помощью [.filename]#documentation/tools/checkkey.sh#. В этом случае убедитесь, что у ключа есть FreeBSD user ID.
 
-=== Правила для коммиттеров документации ([.filename]#doc/#) при работе с деревом исходных текстов ([.filename]#src/#)
+Для тех, у кого ещё нет ключа OpenPGP или требуется новый ключ, соответствующий требованиям безопасности FreeBSD, здесь показано, как его сгенерировать.
 
-* Коммиттеры документации могут самостоятельно изменять документацию к исходным текстам, например, страницы справочника, файлы README, базы данных утилиты fortune, календарей, а также исправлять комментарии в исходных текстах без дополнительного согласования с коммиттерами исходных текстов, при условии сохранения здравого смысла и манеры коммитов.
-* Коммиттеры документации могут вносить незначительные изменения и исправления в исходные тексты (такие как исправления к процессу сборки, добавление малых дополнительных возможностей и т.п.) при наличии одобрения от коммиттера исходных текстов.
-* Коммиттер документации может расширить область действия своего бита на область исходных текстов (и стать, таким образом, коммиттером исходных текстов), найдя себе ментора, который предложит это расширение Правлению (Core). После одобрения, строка с его именем пользователя вносится в файл 'access', и применяются обычные правила периода работы с ментором, подразумевающие получение одобрения на каждый коммит.
-* Одобрение коммита ("Approved by") может производиться только "полновесным" (не работающим с ментором) коммиттером исходных текстов; последние могут рассматривать предлагаемые изменения и указываться в строке "Reviewed by".
+[[pgpkeys-create-steps]]
+[.procedure]
+====
+. Установите [.filename]#security/gnupg#. Добавьте следующие строки в [.filename]#~/.gnupg/gpg.conf#, чтобы задать минимально приемлемые настройки для подписи и предпочтений новых ключей (подробнее см. в link:https://www.gnupg.org/documentation/manuals/gnupg/GPG-Options.html[документации по опциям GnuPG]):
++
+[.programlisting]
+....
+# Sorted list of preferred algorithms for signing (strongest to weakest).
+personal-digest-preferences SHA512 SHA384 SHA256 SHA224
+# Default preferences for new keys
+default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 CAST5 BZIP2 ZLIB ZIP Uncompressed
+....
+. Сгенерировать ключ:
++
+[source, shell]
+....
+% gpg --full-gen-key
+gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Warning: using insecure memory!
+Please select what kind of key you want:
+   (1) RSA and RSA (default)
+   (2) DSA and Elgamal
+   (3) DSA (sign only)
+   (4) RSA (sign only)
+Your selection? 1
+RSA keys may be between 1024 and 4096 bits long.
+What keysize do you want? (2048) 2048 <.>
+Requested keysize is 2048 bits
+Please specify how long the key should be valid.
+	 0 = key does not expire
+      <n>  = key expires in n days
+      <n>w = key expires in n weeks
+      <n>m = key expires in n months
+      <n>y = key expires in n years
+Key is valid for? (0) 3y <.>
+Key expires at Wed Nov  4 17:20:20 2015 MST
+Is this correct? (y/N) y
+GnuPG needs to construct a user ID to identify your key.
+
+Real name: Chucky Daemon <.>
+Email address: [email protected]
+Comment:
+You selected this USER-ID:
+"Chucky Daemon <[email protected]>"
+
+Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
+You need a Passphrase to protect your secret key.
+....
+
+<.> 2048-битные ключи с трехлетним сроком действия обеспечивают достаточную защиту на данный момент (2022-10).
+
+<.> Срок действия ключа в три года достаточно мал, чтобы устаревшие ключи, ослабленные растущей мощностью компьютеров, перестали использоваться, но достаточно велик, чтобы уменьшить проблемы управления ключами.
+
+<.> Используйте здесь своё настоящее имя, предпочтительно совпадающее с указанным в удостоверении личности, выданном государством, чтобы другим было проще подтвердить вашу личность. Текст, который может помочь другим идентифицировать вас, можно ввести в раздел `Комментарий`.
++
+После ввода адреса электронной почты запрашивается парольная фраза. Методы создания безопасной парольной фразы вызывают споры. Вместо того чтобы предлагать один способ, вот несколько ссылок на сайты, описывающие различные методы: https://world.std.com/~reinhold/diceware.html[], https://www.iusmentis.com/security/passphrasefaq/[], https://xkcd.com/936/[], https://en.wikipedia.org/wiki/Passphrase[].
+====
+
+Защитите закрытый ключ и парольную фразу. Если закрытый ключ или парольная фраза могли быть скомпрометированы или раскрыты, немедленно уведомите mailto:[email protected][[email protected]] и отзовите ключ.
+
+Фиксация нового ключа показана в crossref:committers-guide[commit-steps, Шаги для новых коммиттеров].
+
+[[kerberos-ldap]]
+== Kerberos и LDAP веб-пароль для кластера FreeBSD
 
-[[cvs.operations]]
-== Работа с CVS
+Кластер FreeBSD требует пароль Kerberos для доступа к определенным сервисам. Пароль Kerberos также служит веб-паролем LDAP, поскольку LDAP проксирует запросы к Kerberos в кластере. Некоторые из сервисов, требующих его, включают:
 
-Подразумевается, что вы уже имеете опыт базовой работы с CVS.
+* https://bugs.freebsd.org/bugzilla[Bugzilla]
 
-`{cvsadm}` являются "владельцами" репозитория CVS и ответственны за все прямые его изменения (в целях чистки или исправления каких-либо вопиющих ошибок коммиттеров при работе с CVS). Если в результате ваших действий с частью репозитория произошел несчастный случай, например, после неверной операции `cvs import` или `cvs tag`, пошлите письмо соответствующей подгруппе `{cvsadm}` (см. следующую таблицу) и сообщите о проблеме. В наиболее серьезных случаях, каÑ
 Ð°ÑŽÑ‰Ð¸Ñ…ся не только какой-либо части репозитория, а дерева CVS в целом, вы можете написать `{cvsadm}`. Пожалуйста, _не
  надо_ писать группе `{cvsadm}` по поводу репозиторного копирования и прочих вопросов, которые может решить соответствующая подгруппа.
+Для создания новой учетной записи Kerberos в кластере FreeBSD или сброса пароля Kerberos для существующей учетной записи с использованием генератора случайных паролей:
 
-[[repomeisters]]Напрямую изменять содержимое репозитория может только группа CVS-мастеров; для обеспечения этого, только CVS-мастера имеют учетные записи на машинах, поддерживающих основной репозиторий.
+[source, shell]
+....
+% ssh kpasswd.freebsd.org
+....
 
 [NOTE]
 ====
-Адреса, на которые следует посылать запросы, зависят от области репозитория, которую требуется поправить:
-
-* ncvs@ - репозиторий [.filename]#/home/ncvs#, основные исходные тексты 
-* pcvs@ - репозиторий [.filename]#/home/pcvs#, порты
-* dcvs@ - репозиторий [.filename]#/home/dcvs#, документация
-* projcvs@ - репозиторий [.filename]#/home/projcvs#, прочие проекты
+Это должно быть выполнено с компьютера за пределами кластера FreeBSD.org.
 ====
 
-Дерево CVS в настоящее время разделено на четыре независимых репозитория: `doc`, `ports`, `projects` и `src`. Для удобства работы пользователей при распространении через CVSup различные деревья комбинируются в одно, с одним служебным каталогом `CVSROOT`.
+Пароль Kerberos также можно установить вручную, войдя в `freefall.FreeBSD.org` и выполнив:
+
+[source, shell]
+....
+% kpasswd
+....
 
 [NOTE]
 ====
-Обратите внимание, что модуль `www`, содержащий исходные тексты http://www.FreeBSD.org[веб-сайта FreeBSD], расположен в репозитории `doc`.
+Если ранее не использовались аутентифицированные через Kerberos службы кластера FreeBSD.org, будет отображено сообщение `Client unknown`. Эта ошибка означает, что сначала необходимо использовать метод `ssh kpasswd.freebsd.org`, показанный выше, для инициализации учётной записи Kerberos.
 ====
 
-В настоящее время, все репозитории CVS располагаются на одной машине, `ncvs.FreeBSD.org`, однако, для обеспечения возможности в будущем разнести их по физически различным машинам, для каждой поддерживается отдельное имя хоста. Их и следует использовать коммиттерам. Наконец, каждый репозиторий расположен в отдельном каталоге. В итоге, общая картина выглядит так:
-[[cvs-repositories-and-hosts]]
-.Репозитории CVS FreeBSD, хосты и каталоги
-[cols="1,1,1", frame="none", options="header"]
-|===
-| Репозиторий
-| Хост
-| Каталог
+[[committer.types]]
+== Типы битов коммита (прав на коммит)
 
-|doc
-|dcvs.FreeBSD.org
-|/home/dcvs
+Репозиторий FreeBSD содержит ряд компонентов, которые в совокупности поддерживают исходный код базовой операционной системы, документацию, инфраструктуру портов сторонних приложений и различные поддерживаемые утилиты. При выделении прав на коммит (commit bits) в FreeBSD указываются области дерева, где эти права могут быть использованы. Как правило, области, связанные с правами, отражают, кто авторизовал их выделение. Дополнительные области п
 олномочий могут быть добавлены позже: в этом случае коммиттер должен следовать стандартной процедуре выдел
 ения прав на коммит для соответствующей области дерева, получив одобрение от соответствующей инстанции и, возможно, наставника для этой области на некоторый период времени.
 
-|ports
-|pcvs.FreeBSD.org
-|/home/pcvs
+[.informaltable]
+[cols="1,1,1", frame="none"]
+|===
 
-|projects
-|projcvs.FreeBSD.org
-|/home/projcvs
+|__Тип коммиттера__
+|__Ответственный__
+|__Компоненты дерева исходного кода__
 
 |src
-|ncvs.FreeBSD.org
-|/home/ncvs
+|srcmgr@
+|src/
+
+|doc
+|doceng@
+|документация doc/, ports/, src/
+
+|ports
+|portmgr@
+|ports/
 |===
 
-Операции с CVS производятся удаленно, путем установки переменной окружения `CVSROOT` (она должна указывать на соответствующий хост и каталог верхнего уровня, например `ncvs.FreeBSD.org``:`[.filename]#/home/ncvs#) и последующего выполнения команд выгрузки и коммита. Многие коммиттеры определяют команды-синонимы, разворачивающиеся в запуск CVS с правильными параметрами. В частности, пользователи оболочки man:tcsh[1] могут добавить следующие строки в свой скрипт н
 ачальной загрузки [.filename]#.cshrc#:
+Биты коммитов, выделенные до разработки концепции областей ответственности, могут быть подходящими для использования во многих частях дерева. Однако здравый смысл подсказывает, что коммиттер, ранее не работавший в определённой области дерева, должен перед коммитом получить рецензирование (review), согласование от соответствующего ответственного лица и/или работать с наставником. Поскольку правила поддержки кода различаются в завиÑ
 Ð¸Ð¼Ð¾ÑÑ‚и от области дерева, это важно как для самого коммиттера, работающего в менее знакомой области, так и дÐ
 »Ñ других участников, работающих с деревом.
 
-[.programlisting]
-....
-alias dcvs cvs -d [email protected]:/home/dcvs
-alias pcvs cvs -d [email protected]:/home/pcvs
-alias projcvs cvs -d [email protected]:/home/projcvs
-alias scvs cvs -d [email protected]:/home/ncvs
-....
+Коммиттерам рекомендуется запрашивать рецензирование своей работы в рамках обычного процесса разработки, независимо от области дерева, в которой происходит работа.
 
-Теперь все операции с CVS могут выполняться на локальной машине, а для внесения изменений в официальное дерево CVS следует использовать команду `__X__cvs commit`. Если вам нужно добавить в проект что-либо совершенно новое (например, исходные тексты сторонних разработчиков), нужно использовать команду `cvs import`; обратитесь к странице справочника по man:cvs[1] за подробностями.
+=== Политика активности коммиттеров в других деревьях
 
-[NOTE]
-====
-Пожалуйста, _не используйте_ команды `cvs checkout` или `cvs update` для синхронизации ваших исходных текстов. Протокол CVS не оптимизирован для удаленной работы и требует значительных накладных расходов со стороны сервера. Пожалуйста, используйте метод синхронизации посредством `cvsup`, а основной хост используйте только для собственно коммитов. Наша распределенная сеть серверов cvsup достаточно развита. При необходимости синхронизации с самыми с
 вежими изменениями вы можете пользоваться машиной `cvsup-master`, которая обладает достаточными ресурсами для удÐ
 °Ð»ÐµÐ½Ð½Ð¾Ð¹ работы с CVS; за нее отвечает `{kuriyama}`. 
-====
+* Все коммиттеры могут изменять файлы [.filename]#src/share/misc/committers-*.dot#, [.filename]#src/usr.bin/calendar/calendars/calendar.freebsd# и [.filename]#ports/astro/xearth/files#.
+* Документационные коммиттеры могут вносить изменения в документацию в файлы [.filename]#src#, такие как руководства, README, базы данных fortune, календарные файлы и исправления комментариев, без одобрения коммиттера src, при условии соблюдения обычных правил и внимания к коммитам.
+* Любой коммиттер может вносить изменения в любое другое дерево с пометкой "Approved by" от некурируемого коммиттера с соответствующими правами. Курируемые коммиттеры (имеющие наставника) могут предоставлять пометку "Reviewed by", но не "Approved by".
+* Коммиттеры могут получить дополнительный бит по обычному процессу: найти наставника, который предложит их srcmgr, doceng или portmgr, в зависимости от ситуации. После одобрения их добавят в 'access', и начнётся стандартный период наставничества, который будет включать продолжение отметки "Approved by" в течение некоторого времени.
 
-Если вам нужно использовать команды CVS `add` и `delete`, так чтобы в реальности переместить часть исходных текстов подобно действию команды man:mv[1], нужно запросить операцию "репозиторного копирования" (repository copy). При этом кто-либо из <<repomeisters,CVS-мастеров>> скопирует необходимые файлы внутри репозитория на нужное место и даст вам знать об этом. Репозиторное копирование производится для сохранения истории (журналов изменения). Возможность отслÐ
 µÐ´Ð¸Ñ‚ÑŒ историю изменений очень ценна для всего проекта FreeBSD.
+[[doc-blanket-approval]]
+==== Неявное (по умолчанию) одобрение для документации
 
-Документация по CVS, учебные материалы и FAQ можно найти по адресу: http://www.cvshome.org/docs/[http://www.cvshome.org/docs/]. Очень полезна также книга Карла Фогеля (Karl Fogel) http://cvsbook.red-bean.com/cvsbook.html[Open Source Development with CVS]. Некоторая полезная информация о CVS на русском языке может быть найдена http://alexm.here.ru/cvs-ru/[здесь].
+Некоторые типы исправлений имеют "одобрение по умолчанию" от {doceng}, что позволяет любому коммиттеру исправлять эти категории проблем в любой части дерева документации. Эти исправления не требуют одобрения или проверки от коммиттера документации, если у автора нет прав на коммит в документацию.
 
-`{des}` написал такой "мини-пример" работы с CVS:
+Общее одобрение применяется к следующим типам исправлений:
 
-. Извлечение нужного модуля из репозитория: команда `co` или `checkout`.
-+
-[source,shell]
-....
-% cvs checkout shazam
-....
-+ 
-Эта команда извлечет копию модуля [.filename]#shazam#. Если модуль с таким именем не существует (не описан в файле modules), будет произведена попытка извлечь директорию верхнего уровня [.filename]#shazam#.
+* Опечатки
+* Тривиальные исправления
 +
-.Полезные опции команды `cvs checkout`
-[cols="1,1", frame="none"]
-|===
-|`-P`
-|Не создавать (точнее, удалить после завершения выполнения) пустые каталоги
-|`-l`
-|Извлекать один уровень каталогов (без подкаталогов)
+Пунктуация, URL-адреса, даты, пути и имена файлов с устаревшей или некорректной информацией, а также другие распространённые ошибки, которые могут ввести читателей в заблуждение.
 
-|`-r__rev__`
-|Извлечь ревизию, ветвь или тег _rev_ для указанного модуля
+За годы в дереве документации были неявно одобрены некоторые случаи. Этот список показывает наиболее распространённые из них:
 
-|`-D__date__`
-|Извлечь состояние модуля в репозитории на момент _date_
-|===
-+ 
-Примеры в применении к FreeBSD:
-
-** Извлечь модуль [.filename]#miscfs#, расположенный в каталоге репозитория [.filename]#src/sys/miscfs#:
-+
-[source,shell]
-....
-% cvs co miscfs
-....
-+ 
-После выполнения вы получите каталог [.filename]#miscfs#, содержащий подкаталоги [.filename]#CVS#, [.filename]#deadfs#, [.filename]#devfs# и т.д. Один из них ([.filename]#linprocfs#) будет пустым.
-** Извлечь те же файлы, но с полным путем:
-+
-[source,shell]
-....
-% cvs co src/sys/miscfs
-....
-+ 
-Теперь у вас есть каталог [.filename]#src#, содержащий подкаталоги [.filename]#CVS# и [.filename]#sys#. Каталог [.filename]#src/sys# содержит подкаталоги [.filename]#CVS# и [.filename]#miscfs# и т.д.
-** Извлечь те же файлы, удалив при этом пустые подкаталоги:
-+
-[source,shell]
-....
-% cvs co -P miscfs
-....
-+ 
-Вы получите каталог [.filename]#miscfs# с подкаталогами [.filename]#CVS#, [.filename]#deadfs#, [.filename]#devfs#... однако без подкаталога [.filename]#linprocfs#, поскольку он не содержит файлов.
-** Извлечь каталог [.filename]#miscfs# без подкаталогов:
-+
-[source,shell]
-....
-% cvs co -l miscfs
-....
-+ 
-Теперь в каталоге [.filename]#miscfs# будет только один подкаталог [.filename]#CVS#.
-** Извлечь модуль [.filename]#miscfs# из ветви 6.X:
-+
-[source,shell]
-....
-% cvs co -rRELENG_6 miscfs
-....
-+ 
-Теперь вы можете изменить исходные тексты и произвести коммит в эту ветвь.
-** Извлечь модуль [.filename]#miscfs# по состоянию на момент выхода 6.0-RELEASE:
+* Изменения в [.filename]#documentation/content/ru/books/porters-handbook/versions/_index.adoc#
 +
-[source,shell]
-....
-% cvs co -rRELENG_6_0_0_RELEASE miscfs
-....
-+ 
-В этом случае вы не сможете внести изменения в репозиторий, поскольку `RELENG_6_0_0_RELEASE` описывает момент времени, а не ветвь разработки.
-** Извлечь модуль [.filename]#miscfs# по состоянию на 15 января 2000 г:
+extref:{porters-handbook}versions[Значения __FreeBSD_version (Руководство по созданию портов)], в основном используется коммиттерами src.
+* Изменения в [.filename]#doc/shared/contrib-additional.adoc#
 +
-[source,shell]
-....
-% cvs co -D'01/15/2000' miscfs
-....
-+ 
-Как и в предыдущем случае, изменения не могут быть записаны.
-** Извлечь модуль [.filename]#miscfs#, каким он был неделю назад:
+Сопровождение раздела extref:{contributors}[Дополнительные участники FreeBSD, contrib-additional].
+* Все link:#commit-steps[Шаги для новых коммиттеров], связанные с документацией
+* Рекомендации по безопасности; Уведомления об ошибках; Релизы;
 +
-[source,shell]
-....
-% cvs co -D'last week' miscfs
-....
-+ 
-И вновь, изменения не могут быть записаны.
-+ 
-Обратите внимание, что мета-данные хранятся в подкаталогах [.filename]#CVS#.
-+ 
-Аргументы опций `-D` and `-r` сохраняются (являются "клейкими", sticky), например, при последующем использовании команды `cvs update`.
-. Проверка состояния извлеченных файлов: команда `status`.
+{security-officer} и {re} используют эти разделы.
+* Изменения в [.filename]#website/content/ru/donations/donors.adoc#
 +
-[source,shell]
-....
-% cvs status shazam
-....
+{donations} использует этот документ.
 
-+ 
-Эта команда покажет статус файла [.filename]#shazam# или каждого файла в директории [.filename]#shazam#. Для каждого из файлов статус может быть одним из:
-+
-[.informaltable]
-[cols="1,1", frame="none"]
-|===
-|Up-to-date
-|Файл соответствует репозиторию и не модифицировался
+Перед любым коммитом необходимо выполнить тестовую сборку; подробности см. в разделах «Обзор» и «Процесс сборки документации FreeBSD» extref:{fdp-primer}[Руководства для новых участников проекта документации FreeBSD].
 
-|Needs Patch
-|Файл не изменялся, но репозиторий содержит обновленную версию
+[[git-primer]]
+== Руководство по Git
 
-|Locally Modified
-|Файл соответствует репозиторию, но был изменен локально
+[[git-basics]]
+=== Основы Git
 
-|Needs Merge
-|Файл изменен локально; вместе с тем, файл изменен и в репозитории
+При поиске по ключевым словам "Git Primer" можно найти множество хороших материалов. Страницы Дэниела Милера link:https://danielmiessler.com/study/git/[Введение в Git] и Вилли Виллуса link:https://gist.github.com/williewillus/068e9a8543de3a7ef80adb2938657b6b[Git - Краткое введение] являются хорошими обзорами. Книга по Git также полная, но гораздо длиннее: https://git-scm.com/book/en/v2. Также обратите внимание на сайт https://dangitgit.com/, посвящённый распространённым ловушкам и подводным камням Git, на случай, если вам Ð
 ½ÑƒÐ¶Ð½Ð¾ исправить ошибки. Наконец, введение, link:https://eagain.net/articles/git-for-computer-scientists/[ориентированное на компьютерныÑ
 … учёных], оказалось полезным для некоторых в объяснении мировоззрения Git.
 
-|File had conflicts on merge
-|После последнего обновления возникли конфликты, и они все еще не устранены
-|===
-+ 
-Кроме того, будут показаны локальная версия и дата модификации, версия и дата последней из доступных (если вы применяли "клейкие" дату, тег или ветвь, последняя доступная версия может отличаться от вашей), а также клейкие теги, временные метки и опции.
-. Обновление извлеченного модуля: команда `update`.
-+
-[source,shell]
-....
-% cvs update shazam
-....
+Этот документ предполагает, что вы уже читали про это, и постарается не повторять основы (хотя кратко их рассмотрит).
 
-+ 
-Эта команда обновит состояние файла [.filename]#shazam# или файлов в каталоге [.filename]#shazam# до наиболее свежих версий выбранной вами при извлечении ветви. Если выбирался "момент времени", не произойдет ничего, если только за истекшее время в репозитории не был перемещен тег или не произошло чего-нибудь еще непредвиденного.
-+ 
-Полезные опции в дополнение к уже описанным для команды `checkout`:
-+
-[.informaltable]
-[cols="1,1", frame="none"]
-|===
-|`-D`
-|Извлечь вновь появившиеся или пропущенные ранее подкаталоги
+[[git-mini-primer]]
+=== Мини-руководство по Git
 
-|`-a`
-|Обновиться до текущего состояния головной ветви
+Это руководство имеет менее амбициозные цели, чем старое руководство по Subversion, но должно охватить основы.
 
-|`-j__rev__`
-|магическая опция (см. ниже)
-|===
-+ 
-Если вы извлекали модуль с опциями `-r` или `-D`, выполнение команды `cvs update` с другими параметрами `-r` или `-D` или с опцией `-a` приведет к выбору новой ветви, ревизии или даты. Использование опции `-a` удаляет использованные ранее клейкие свойства; опции `-r` и `-D`, наоборот, фиксируют их.
-+ 
-Теоретически использование `HEAD` в качестве аргумента опции `-r` должно дать тот же результат, что и указание опции `-a`, однако это верно лишь в теории.
-+ 
-Опция `-D` полезна, если:
+==== Область применения
 
-** после извлечения вами модуля кем-либо еще в него были добавлены дополнительные каталоги;
-** вы извлекали верхний уровень модуля при помощи опции `-l`, а в дальнейшем решили извлечь и подкаталоги;
-** вы удалили какие-либо подкаталоги и теперь хотите вновь извлечь их.
+Если вы хотите загрузить FreeBSD, собрать его из исходных кодов и в целом поддерживать актуальность таким способом, это руководство для вас. Оно охватывает получение исходных кодов, их обновление, бинарный поиск (bisect) и кратко затрагивает способы работы с локальными изменениями. В нём изложены основы, а также даны полезные ссылки на более глубокие материалы для случаев, когда читателю будет недостаточно базовой информации. Другие разде
 лы этого руководства посвящены более сложным темам, связанным с участием в проекте.
 
-+ 
-__Обращайте внимание на вывод команды `cvs update`.__ Действие, произведенное с файлом, обозначается буквой перед его именем:
-+
-[.informaltable]
-[cols="1,1", frame="none"]
-|===
-|`U`
-|Файл был успешно обновлен.
+Цель этого раздела — выделить те аспекты Git, которые необходимы для отслеживания исходных кодов. Предполагается базовое понимание Git. В интернете есть множество вводных руководств по Git, но https://git-scm.com/book/en/v2[Книга по Git] предлагает одно из лучших изложений.
 
-|`P`
-|Файл был успешно обновлен (произведен успешный патч из удаленного репозитория).
+[[git-mini-primer-getting-started]]
+==== Начало работы для разработчиков
 
-|`M`
-|Файл был изменен, и при этом обновлен успешно.
+Этот раздел описывает доступ на чтение и запись для коммиттеров, чтобы отправлять коммиты от разработчиков или контрибьюторов.
 
-|`C`
-|Файл был изменен, и при объединении изменений возникли конфликты.
-|===
-+ 
-Объединение (merging) производится, если вы выгрузили рабочую копию какого-то модуля, изменили его, затем кто-либо еще произвел коммит собственных изменений, и, наконец, вы выполняете команду `cvs update`. CVS знает, что производились локальные изменения, и пытается объединить ваши изменения с теми, что произошли в репозитории (от состоянии версии, которую вы выгружали, до версии, до которой вы пытаетесь обновиться). Если изменения происходили с 
 различными частями файла, объединение почти всегда произойдет успешно (хотя результат при этом может не быт
 ь синтаксически или семантически корректным).
-+ 
-CVS выводит букву `M` перед именем всех локально измененных файлов, даже если у них нет новых версий в репозитории, так что команда `cvs update` удобна для быстрого получения списка файлов, которые вы изменяли.
-+ 
-Если в результате вы видите букву `C`, ваши изменения конфликтуют с изменениями, внесенными в репозиторий (изменения были в одних и тех же или рядом расположенных строках, либо вы изменили файл настолько, что при сравнении `cvs` не смогла удержать контекст и приложить изменения из репозитория). Вам необходимо устранить конфликты, вручную редактируя файл. Конфликтующие фрагменты помечаются строками из знаков `<`, `=` и `>`. В начале каждого иÐ
 · конфликтов присутствует строка из семи знаков `<` и имени файла, затем идет фрагмент, содержащий внесенные в
 ами изменения, разделитель из семи знаков `=`, соответствующий фрагмент из версии файла, содержащейся в репозитории, и, наконец, строка из семи знаков `>` совместно с номером версии, до которой вы обновляли файл.
-+ 
-Опция `-J` содержит некоторое количество черной магии. При ее наличии локальный файл обновляется до указанной версии так же, как и при использовании опции `-r`, но отслеживаемые номер версии или ветвь не изменяются. Эта опция умеет смысл лишь при парном использовании: при этом делается попытка применить изменения между двумя указанными версиями к локальной копии файла.
-+ 
-К примеру, вы внесли изменения и произвели коммит в файл [.filename]#shazam/shazam.c# в FreeBSD-CURRENT, а позднее хотите перенести обновления в FreeBSD-STABLE (Merge-From-Current, MFC). Версия, которая требует переноса - 1.15:
-
-** Извлеките текущую версию модуля [.filename]#shazam# для ветви FreeBSD-STABLE:
-+
-[source,shell]
-....
-% cvs co -rRELENG_6 shazam
-....
+[[git-mini-daily-use]]
+===== Повседневное использование
 
-** Приложите изменения между версиями 1.14 и 1.15:
-+
-[source,shell]
-....
-% cvs update -j1.14 -j1.15 shazam/shazam.c
-....
-+ 
-Почти наверняка вы получите конфликт в строках, содержащих идентификатор файла (`$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $` или, в случае FreeBSD, `$FreeBSD: head/ru_RU.KOI8-R/articles/committers-guide/article.xml 45050 2014-06-13 14:53:24Z taras $`). Вам потребуется отредактировать файл для устранения конфликта (в данном случае достаточно убрать строки-разделители и вторую строку `$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $`, оставив лишь строку с `$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $` для FreeBSD-STABLE).
-. Просмотр изменение между локальной версией и версией из репозитория: команда `diff`.
-+
-[source,shell]
-....
-% cvs diff shazam
-....
-+ 
-Эта команда покажет все отличия локального состояния файла (или файлов модуля) [.filename]#shazam# от состояния, сохраненного в репозитории.
-+
-.Полезные опции команды `cvs diff`
-[cols="1,1", frame="none"]
-|===
-|`-u`
-|Использовать унифицированный (unified) формат.
-|`-c`
-|Использовать контекстный (context) формат.
+[NOTE]
+====
+В приведенных ниже примерах замените `${repo}` на имя нужного репозитория FreeBSD: `doc`, `ports` или `src`.
+====
 
-|`-N`
-|Показывать отсутствующие или созданные файлы.
-|===
-+ 
-Всегда имеет смысл пользоваться опцией `-u`, поскольку унифицированный формат гораздо удобнее и лучше читаем, чем почти все другие (в некоторых случаях контекстный формат, генерируемый опцией `-c` может быть несколько лучше, но он гораздо более громоздок). Унифицированный формат различий состоит из серии фрагментов, каждый из которых начинается со строки, состоящей из двух символов `@` и номеров строк, описывающих положение изменившего
 ся участка. Затем следует группа строк: те, что начинаются с пробела, описывают контекст, начинающиеся с симв
 ола `-` определяют удаленные строки, наконец, начинающиеся с символа `+` - добавленные.
-+ 
-Вы можете сравнивать текущее состояние с версией, отличающейся от той, с которой вы извлекали файл, указав опцию `-r` или `-D` подобно командам `checkout` и `update`, или даже получить список изменений между любыми двумя версиями (вне зависимости от того, что лежит в вашей локальной копии), указав _две_ версии при помощи опций `-r` или `-D`.
-. Просмотр журнала изменений: команда `log`.
+* Клонировать репозиторий:
 +
-[source,shell]
+[source, shell]
 ....
-% cvs log shazam
+% git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://git.freebsd.org/${repo}.git
 ....
-+ 
-Если [.filename]#shazam# является обычным файлом, эта команда выдаст на экран _заголовок_ с информацией о файле, в частности, его местоположении в репозитории, какая версия соответствует текущему состоянию (`HEAD`), в каких ветвях разработки файл присутствует, а также перечислит теги, которыми он помечен. Затем, для каждой версии файла выводится соответствующее ей журнальное сообщение, включающее дату, время и автора коммита, количество добавлеÐ
 ½Ð½Ñ‹Ñ… и удаленных строк и собственно журнального сообщения, написанного коммиттером.
-+ 
-Если [.filename]#shazam# является каталогом, вышеописанная процедура выполняется для каждого файла в каталоге. Если при этом команде `log` не был указан флаг `-l`, процедура рекурсивно повторяется для всех подкаталогов.
-+ 
-Команда `log` используется для просмотра истории одного или нескольких файлов в том виде, как она сохранена в репозитории CVS. Используя опцию `-r__rev__`, вы можете посмотреть журнальное сообщение к одной определенной версии:
 +
-[source,shell]
-....
-% cvs log -r1.2 shazam
-....
-+ 
-Эта команда покажет журнальное сообщение для версии `1.2` файла [.filename]#shazam# (или для версий `1.2` каждого из файлов в каталоге [.filename]#shazam#).
-. Кто что делал: команда `annotate`. Эта команда показывает перед каждой строкой указанного файла (файлов) имя пользователя, вносившего последние изменения в эту строку.
+В результате у вас в качестве удалённых (remote) должны быть официальные зеркала:
 +
-[source,shell]
+[source, shell]
 ....
-% cvs annotate shazam
+% git remote -v
+freebsd  https://git.freebsd.org/${repo}.git (fetch)
+freebsd  https://git.freebsd.org/${repo}.git (push)
 ....
 
-. Добавление новых файлов: команда `add`.
-+ 
-Создайте файл, выполните для него команду `cvs add`, затем произведите запись в репозиторий (коммит): `cvs commit`.
-+ 
-Точно так же, новые каталоги добавляются в репозиторий путем создания и последующего выполнения команды `cvs add`. Заметьте, что выполнять коммит после добавления каталога не надо.
-. Удаление устаревших файлов: команда `remove`.
-+ 
-Удалите файл, затем выполните команду `cvs rm` с его именем в качестве параметра, наконец, выполните для него `cvs commit`.
-. Внесение изменений в репозиторий: команда `commit` или `checkin`.
+* Настройка данных коммиттера FreeBSD:
 +
-.Useful `cvs commit` options
-[cols="1,1", frame="none"]
-|===
-|`-F`
-|Форсировать внесение изменений для не модифицированного файла.
-|`-m__msg__`
-|Указать сообщение для журнала в командной строке (не запускать текстовый редактор).
-|===
-+ 
-Опцию `-F` следует использовать, если вы поняли, что забыли указать какую-либо важную информацию в журнале изменений.
-+ 
-Хорошие журнальные сообщения очень важны. Они дают возможность другим узнать, зачем вы производили изменения, причем не только в момент их произведения, но и месяцы или годы спустя, когда кто-либо заинтересуется, почему выглядящий нелогично или неэффективно фрагмент кода попал в каши исходные тексты. Кроме того, это очень помогает в оценке того, нужно ли переносить соответствующий код в FreeBSD-STABLE (MFC).
-+ 
-Сообщения должны быть ясными, краткими, четкими, и представлять из себя разумную аннотацию, какие изменения были произведены и почему.
-+ 
-Сообщения должны достаточно ясно показывать сторонним разработчикам, насколько их касаются изменения и нужно ли им исследовать изменения подробно.
-+ 
-Избегайте внесения нескольких не связанных друг с другом изменений за один раз. Это затрудняет объединение изменений, а также, при обнаружении ошибок, усложняет поиск ответственного за ошибки участка.
-+ 
-Избегайте смешивания в одном коммите изменений функциональности со стилистическими правками или исправлениями в пробелах. Это усложняет объединение, и, кроме того, затрудняет понимание того, какие именно функциональные изменения были внесены. В случае коммита в файлы документации, это затруднит работу групп поддержки перевода, поскольку становится сложнее отделить изменения, требующие перевода.
-+ 
-Избегайте коммита большой группы файлов за один раз с одним общим и невнятным сообщением. Напротив, вносите изменения в отдельные файлы (или небольшие группы связанных файлов) с адекватными сообщениями для журналирования.
-+ 
-Перед коммитом, __обязательно__:
-
-** проверьте, что вы будете выполнять коммит в правильную ветвь, посредством команды `cvs status`.
-** проверьте ваши изменения при помощи команды `cvs diff`
-
-+ 
-Кроме того, ВСЕГДА указывайте, в какие именно файлы вы вносите изменения, так чтобы не включить в этот список лишних файлов. Команда `cvs commit` без аргументов включит все измененные файлы в текущем каталоге и всех подкаталогах. 
-
-Еще несколько полезных советов:
-
-. Часто используемые опции можно занести в файл [.filename]#~/.cvsrc#, например:
+Хук для коммита в repo.freebsd.org проверяет, что поле "Commit" соответствует информации о коммиттере в FreeBSD.org. Самый простой способ получить предлагаемую конфигурацию — выполнить скрипт `/usr/local/bin/gen-gitconfig.sh` на freefall:
 +
-[.programlisting]
+[source, shell]
 ....
-cvs -z3
-diff -Nu
-update -Pd
-checkout -P
+% gen-gitconfig.sh
+[...]
+% git config user.name (your name in gecos)
+% git config user.email (your login)@FreeBSD.org
 ....
-+ 
-Для данного случая:
-
-** всегда использовать компрессию уровня 3 для связи с удаленным сервером CVS. В случае медленного соединения это избавит вас от лишней головной боли.
-** всегда использовать опции `-N` (показывать добавленные или удаленные файлы) и `-u` (унифицированный формат) для man:diff[1].
-** всегда использовать опции `-P` (удалять пустые каталоги) и `-D` (добавлять новые каталоги) при обновлении.
-** всегда использовать опцию `-P` (удалять пустые каталоги) при извлечении файлов и модулей.
 
-. Пользуйтесь скриптом Эйвинда Эклунда (Eivind Eklund) `cdiff` для просмотра изменению унифицированного формата. Он является оберткой для man:less[1], добавляющей цветовые коды ANSI для выделения заголовком, добавленных и удаленных строк; прочие строки не модифицируются. Помимо этого, скрипт корректно разворачивает табуляции (которые часто выглядят неправильно в изменениях из-за дополнительного символа в начале строки).
-+ 
-package:textproc/cdiff[]
-+ 
-Просто используйте его вместо man:more[1] или man:less[1]:
+* Установите URL для отправки (push URL):
 +
-[source,shell]
+[source, shell]
 ....
-% cvs diff -Nu shazam | cdiff
+% git remote set-url --push freebsd [email protected]:${repo}.git
 ....
-+ 
-Помимо этого, некоторые текстовые редакторы, такие как man:vim[1] (package:editors/vim[]) поддерживают цветовую синтаксическую разметку многих типов файлов, в том числе файлов изменений и журналов CVS/RCS.
 +
-[source,shell]
+В таком случае у вас должны быть раздельные URL для извлечения (fetch) и отправки (push) как наиболее эффективная настройка:
++
+[source, shell]
 ....
-% echo "syn on" >> ~/.vimrc
-% cvs diff -Nu shazam | vim -
-% cvs log shazam | vim -
+% git remote -v
+freebsd  https://git.freebsd.org/${repo}.git (fetch)
+freebsd  [email protected]:${repo}.git (push)
 ....
++
+Еще раз обратите внимание, что `gitrepo.freebsd.org` является псевдонимом для `repo.freebsd.org`.
 
-. CVS - старая, загадочная и порой слабо предсказуемая в своем поведении программа.  Ни один человек не способен удержать в голове все тонкости ее работы, так что не бойтесь спрашивать совета у Искусственного Интеллекта (а именно `{cvsadm}`).
-. Не оставляйте компьютер в процессе работы команды `cvs commit` (в редакторе при написании журнального сообщения) слишком надолго (более чем на 2-3 минуты). Эта команда блокирует каталог репозитория, в котором она запущена, и не позволяет другим разработчикам изменять его содержимое. Если вам нужно написать длинное журнальное сообщение, подготовьте его заранее и вставьте в редакторе во время выполнения команды `cvs commit`, либо запишите его в Ñ
 „айл и используйте опцию CVS `-F`:
+* Установка хука для шаблона сообщения коммита:
 +
-[source,shell]
+Для репозитория документации:
++
+[source, shell]
 ....
-% vi logmsg
-% cvs ci -F logmsg shazam
+% cd .git/hooks
+% ln -s ../../.hooks/prepare-commit-msg
 ....
-+ 
-Это самый быстрый способ передать журнальное сообщение CVS; однако, вы должны быть внимательны при редактировании файла [.filename]#logmsg#, поскольку при выполнении коммита у вас не будет шансов его поправить.
-. Вы можете существенно ускорить скорость работы CVS с центральным репозиторием, используя постоянное соединение с репозиторием. Для этого добавьте в файл [.filename]#~/.ssh/config# строки 
 +
-[.programlisting]
+Для репозитория портов:
++
+[source, shell]
 ....
-Host ncvs.FreeBSD.org
-      ControlPath /home/user/.ssh/cvs.cpath
-Host dcvs.FreeBSD.org
-      ControlPath /home/user/.ssh/cvs.cpath
-Host projcvs.FreeBSD.org
-      ControlPath /home/user/.ssh/cvs.cpath
-Host pcvs.FreeBSD.org
-      ControlPath /home/user/.ssh/cvs.cpath
+% git config --add core.hooksPath .hooks
 ....
-+ 
-Затем откройте постоянное соединение с машиной repoman:
 +
-[source,shell]
+Для репозитория src:
++
+[source, shell]
 ....
-% ssh -fNM ncvs.FreeBSD.org
+% cd .git/hooks
+% ln -s ../../tools/tools/git/hooks/prepare-commit-msg
 ....
-+ 
-Теперь команды CVS должны выполняться быстрее, поскольку используют существующее соединение с репозиторием. Учтите, что регистр в именах хостов имеет значение.
 
-[[conventions]]
-== Соглашения и традиции
+[[admin-branch]]
+===== Ветка "admin"
 
-Став коммиттером, вы должны прежде всего произвести некоторые стандартные действия.
+Файлы `access` и `mentors` хранятся в отдельной (orphan) ветке `internal/admin` в каждом репозитории.
 
-* Добавьте себя в список "SGML сущностей" авторов в файл [.filename]#doc/en_US.ISO8859-1/shared/xml/authors.ent#; это изменение должно быть сделано прежде прочих, поскольку в противном случае следующий ваш коммит неизбежно разрушит процесс построения дерева doc/.
-+ 
-Это довольно простая задача, но при этом она является неплохим первым тестом ваших навыков работы с CVS.
-* Также добавьте свою "SGML сущность" в [.filename]#www/en/developers.xml#.
-* Добавьте себя в раздел "Разработчики" статьи extref:{contributors}[Участники проекта FreeBSD] ([.filename]#doc/en_US.ISO8859-1/articles/contributors/contrib.committers.xml#) и удалите свою запись из раздела "Прочие участники" ([.filename]#doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml#).
-* Добавьте новость о новом коммиттере в файл [.filename]#www/shared/xml/news.xml#. Используйте существующие записи вида "Новый коммиттер" как шаблон.
-* Вам нужно добавить ваш PGP или GnuPG ключ в каталог [.filename]#doc/shared/pgpkeys# (а если у вас нет ключа, вам нужно его создать). Не забудьте изменить и произвести коммит в файл [.filename]#doc/shared/pgpkeys/pgpkeys.ent#.
-+ 
-`{des}` написал скрипт для упрощения этого процесса. Дополнительную информацию можно прочесть в файле http://cvsweb.FreeBSD.org/doc/shared/pgpkeys/README[README].
-+
-[NOTE]
-====
-Очень важно, чтобы в Руководстве пользователя был записан актуальный PGP/GnuPG ключ, поскольку он может потребоваться для идентификации коммиттера (например, его будет проверять группа `{admins}` для аварийного восстановления учетной записи). Полный набор актуальных ключей пользователей домена `FreeBSD.org` можно найти по адресу link:https://www.FreeBSD.org/doc/pgpkeyring.txt[http://www.FreeBSD.org/doc/pgpkeyring.txt].
-====
-* Добавьте себя в файл [.filename]#src/shared/misc/committers-репозиторий.dot#, где репозиторием будет являться либо doc, либо ports, либо src в зависимости от полученных вами коммиттерских привилегий.
-* Некоторые коммиттеры добавляют информацию о своем местоположении в файл [.filename]#ports/astro/xearth/files/freebsd.committers.markers#.
-* Некоторые добавляют данные о дне своего рождения в файл [.filename]#src/usr.bin/calendar/calendars/calendar.freebsd#.
-* Представьтесь другим коммиттерам, иначе никто не будет знать, кто вы и чем занимаетесь. От вас не требуется писать подробное резюме или биографию: будут достаточны один-два абзаца о себе и областях FreeBSD, в которых вы планируете работать. Пошлите это письмо в {src-developers-name} - и все!
-* Зайдите на машину `hub.FreeBSD.org` и создайте файл [.filename]#/var/forward/user# (замените _user_ на ваше имя пользователя). Этот файл должен содержать адрес электронной почты, на который будет переправляться вся почта на адрес [email protected], в том числе сообщения о коммитах и другая почта на адреса {committers-name} и {src-developers-name}. Слишком большие почтовые ящики на машине `hub` могут быть "нечаянно" удалены или обрезаны без предупреждения, так что, чтобы не потерять Ð
 ¿Ð¾Ñ‡Ñ‚у, регулярно читайте ее либо перенаправьте куда-нибудь еще.
-+ 
-Из-за ощутимой загрузки, возникающей на серверах, обрабатывающих списки рассылки, из-за большого количества незапрошенной почты (спама), сервер, принимающий почту для домена FreeBSD.org, производит некоторые основные проверки и на основании их отвергает некоторые письма. На настоящий момент единственным проверяемым параметром является корректность информации DNS для хоста, доставляющего почту, но в будущем список может вырасти. Эти пров
 ерки временами обвиняют в том, что они отвергают правильную почту. Если вы хотите отключить проверки для сво
 его адреса, создайте файл [.filename]#~/.spam_lover# в своей домашней директории на машине `freefall.FreeBSD.org`.
-* Если вы были подписаны на {cvs-all}, вам, скорее всего, следует отписаться от него, чтобы не получать дубликатов каждого сообщения о коммитах.
+Следующий пример показывает, как переключиться (check out) на ветку `internal/admin` в локальной ветке с именем `admin`:
 
-Все новые коммиттеры первоначально работают под руководством ментора. Ваш ментор отвечает за обучение вас правилам и соглашениям, принятым в проекте, и помогает вам сделать первые шаги в среде коммиттеров. Он(а) также персонально отвечает за ваши действия в этот начальный период. До тех пор, пока ваш ментор не решит (и не анонсирует это посредством форсированного коммита файла [.filename]#access#), что вы достаточно освоились и готовы работат
 ь самостоятельно, перед любым коммитом вы должны получить одобрение (approval) ментора и указать это в журнально
 м сообщении коммита строкой `Approved by:`.
+[source, shell]
+....
+% git config --add remote.freebsd.fetch '+refs/internal/*:refs/internal/*'
+% git fetch
+% git checkout -b admin internal/admin
+....
+В качестве альтернативы вы можете добавить рабочее дерево для ветки `admin`:
 
-Все коммиты в дерево [.filename]#src# сначала должны производиться в ветвь FreeBSD-CURRENT и лишь затем интегрироваться в FreeBSD-STABLE. Никакие серьезные изменения, новые возможности или рискованные модификации не должны производиться напрямую в ветви FreeBSD-STABLE.
+[source, shell]
+....
+git worktree add -b admin ../${repo}-admin internal/admin
+....
 
-[[pref-license]]
-== Предпочтительная лицензия для новых файлов
+Для просмотра ветки `internal/admin` в веб-интерфейсе: `https://cgit.freebsd.org/${repo}/log/?h=internal/admin`
 
-В настоящее время Проект FreeBSD считает предпочтительной формой лицензии на исходные тексты следующий текст:
+Для отправки (push) укажите полную спецификацию ссылки:
 
-[.programlisting]
+[source, shell]
+....
+git push freebsd HEAD:refs/internal/admin
 ....
-/*-
-* Copyright (c) [year] [your name]
-* All rights reserved.
-*
-* Redistribution and use in source and binary forms, with or without
-* modification, are permitted provided that the following conditions
-* are met:
-* 1. Redistributions of source code must retain the above copyright
-*    notice, this list of conditions and the following disclaimer.
-* 2. Redistributions in binary form must reproduce the above copyright
-*    notice, this list of conditions and the following disclaimer in the
-*    documentation and/or other materials provided with the distribution.
-*
-* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
-* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-* ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
-* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-* SUCH DAMAGE.
-*
-* [id for your version control system, if any]
-*/
-....
-
-Проект FreeBSD крайне не рекомендует так называемый "третий пункт", или "пункт о рекламе" в лицензии на новый исходный код. В связи с большим количеством участников проекта FreeBSD, выполнение этого пункта большинством коммерческих производителей все более затруднительно. Если ваш код в дереве исходников содержит "пункт о рекламе", рассмотрите возможность его удаления. На самом деле, рассмотрите возможность перехода на приведенную лицензи
 ю.
-
-Проект FreeBSD не рекомендует использование полностью новых лицензий или вариаций стандартных лицензий. Новые лицензии перед использованием в репозитории проекта требуют утверждения группой mailto:[email protected][[email protected]]. Большое число различных лицензий затрудняет использование кода, в основном из-за ненамеренных неверных выводов из плохо сформулированных формулировок лицензии.
-
-Политика проекта требует, чтобы код под НЕ-BSD лицензиями располaгался только в определённых местах репозитория, а в некоторых случаях компиляция должна быть условной по умолчанию или вообще отключена. К примеру, ядро GENERIC должно состоять только из лицензий идентичных или в значительной степени схожих с BSD лицензией. Программное обеспечение под лицензиями GPL, APSL, CDDL и др. не должно включаться в состав GENERIC.
-
-Разработчикам напоминается, что в open source правильное понимание "open" также важно, как правильное понимание "source", ибо некорректное использование интеллектуальной собственности имеет серьезные последствия. Какие-либо вопросы или беспокойства на этот счёт должны быть немедленно вынесены на обсуждение главной команде разработчиков (core team).
-
-[[developer.relations]]
-== Взаимодействие между разработчиками
 
-Если вы работаете над собственным исходным кодом, либо в области, в которой вы уже определены как ответственная персона, вам, скорее всего, не потребуется согласовывать коммит с кем-либо еще из разработчиков. Те же правила действуют, если вы нашли ошибку в той части системы, которой явно давно никто не занимается (к нашему стыду, существует несколько таких областей). Если же вы собираетесь модифицировать что-либо активно поддерживаемÐ
 ¾Ðµ (по-хорошему, узнать это можно только исследуя архивы списка рассылки `cvs-committers`), стоит послать предполагаÐ
 µÐ¼Ñ‹Ð¹ патч ответственному за этот участок кода, как вы бы поступали, пока не были коммиттером. В случае портов нужно обращаться по адресу, указанному в строке `MAINTAINER` в файле [.filename]#Makefile#. Для других частей репозитория, в случае если вам не очевидно, кто ведет данный участок кода, может помочь исследование вывода команды `cvs log`. `{fenner}` написал отличный скрипт для определения разработчиков, наиболее активно производивших коммиты, выводящий
  для каждого из указанных файлов имя пользователя вместе с количеством произведенных им коммитов в данный ф
 айл. Скрипт можно найти Ð!
 ½Ð° машине `freefall` в файле [.filename]#~fenner/bin/whodid#. Если найденная вами персона не отвечает на ваши вопросы или иным образом демонстрирует отсутствие интереса к проблеме, смело производите коммит самостоятельно.
+==== Как поддерживать актуальную копию дерева исходных кодов FreeBSD src
+[[keeping_current]]
+Первый шаг: клонирование дерева. Это загружает всё дерево целиком. Существует два способа загрузки. Большинству пользователей потребуется глубокое клонирование репозитория. Однако бывают случаи, когда может потребоваться поверхностное клонирование.
 
-Если вы по каким-либо причинам не уверены в своих изменениях, предложите их для оценки в списке рассылки `-hackers` перед коммитом. Будет лучше, если вас обругают там и тогда, чем когда предлагаемое изменение уже будет частью репозитория. Если случилось так, что ваш коммит встретил сопротивление, возможно, стоит его откатить (back out) до тех пор, пока не будет достигнут консенсус. Помните - с помощью CVS всегда можно вернуться к предыдущему состÐ
 ¾ÑÐ½Ð¸ÑŽ.
+===== Названия веток
+FreeBSD-CURRENT использует ветку `main`.
 
-Не принимайте в штыки мнения других разработчиков, с которыми вы не согласны. Если они предлагают иное решение проблемы чем вы, или даже иначе воспринимают проблему, это не значит, что они глупы, имеют сомнительное происхождение, хотят разрушить вашу работу, очернить ваше доброе имя, или развалить проект FreeBSD. Просто они смотрят на мир под иным углом. Различные взгляды - благо.
+`main` — это ветка по умолчанию.
 
-Будьте честны в спорах. Оценивайте свою позицию по заслугам, честно относитесь к ее слабым сторонам и будьте готовы принять другие точки зрения и пути решения. Будьте открыты.
+Для FreeBSD-STABLE названия веток включают `stable/12` и `stable/13`.
 
-Будьте терпимы, если вас поправляют. Все мы совершаем ошибки. Если вы ошиблись, извинитесь. Не обвиняйте ни себя, ни, тем более, других в ошибке. Не теряйте времени на смущение или упреки, просто исправьте ошибку и двигайтесь дальше.
+Для FreeBSD-RELEASE, названия веток разработки выпусков включают `releng/12.4` и `releng/13.2`.
 
-Спрашивайте и просите о помощи. Предлагайте ваши изменения для рассмотрения коллегам и рассматривайте их изменения. Одним из преимуществ программного обеспечения с открытыми исходными текстами является открытость разработки. Если никто не будет исследовать чужой код, это преимущество исчезнет.
+https://www.freebsd.org/releng/[] отображает:
 
-[[gnats]]
-== GNATS
+* ветки `main` и `stable/⋯` открыты
+* ветки `releng/⋯`, каждая из которых замораживается при создании тега релиза.
 
-Для отслеживания ошибок и запросов на изменения проект FreeBSD использует GNATS. Если вы исправили ошибку или внесли изменения, описанные в одном из сообщений об ошибках (PR), не забудьте закрыть это сообщение, используя команду `edit-pr _pr-number_` на машине `freefall`. Хорошо будет, если вы потратите немного времени на поиск и закрытие других PR по этой теме. Вы и сами можете пользоваться man:send-pr[1] для предложения изменений, которые, по вашему мнению, могут
  потребовать более подробного обсуждения с коллегами.
+Примеры:
 
-Более подробно о GNATS можно прочитать по адресам:
+* тег https://cgit.freebsd.org/src/tag/?h=release/13.1.0[release/13.1.0] на ветке https://cgit.freebsd.org/src/log/?h=releng/13.1[releng/13.1]
+* тег https://cgit.freebsd.org/src/tag/?h=release/13.2.0[release/13.2.0] на ветке https://cgit.freebsd.org/src/log/?h=releng/13.2[releng/13.2].
 
-* http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html[http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html]
-* link:https://www.FreeBSD.org/support/[http://www.FreeBSD.org/support/]
-* man:send-pr[1]
+===== Репозитории
+Пожалуйста, обратитесь к разделу crossref:committers-guide[admin,Административные детали] для получения актуальной информации о том, где взять исходные коды FreeBSD. Значение $URL ниже можно получить с этой страницы.
 
-Вы можете пользоваться локальной копией GNATS, поддерживая ее синхронность при помощи CVSup. При этом вы можете использовать команды GNATS локально, а также пользоваться другими интерфейсами, такими как `tkgnats`, что позволит вам работать с базой сообщений об ошибках без соединения с Интернет.
+Примечание: Проект не использует подмодули, так как они плохо подходят для наших рабочих процессов и модели разработки. То, как мы отслеживаем изменения в сторонних приложениях, обсуждается в другом месте и, как правило, мало интересует обычного пользователя.
 
-[.procedure]
-.Procedure: Использование локальной копии GNATS
-. Если вы еще не поддерживаете зеркало дерева GNATS, добавьте в ваш [.filename]#supfile# строку
-+
-[.programlisting]
-....
-gnats release=current prefix=/usr
-....
-+ 
-Учтите, что эта строка должна предшествовать любым строкам, содержащим параметр "tag=", поскольку дерево GNATS не находится под управлением CVS и не имеет символьных меток.
-+ 
-После запуска cvsup в каталоге [.filename]#/usr/gnats# будет создана копия дерева GNATS FreeBSD. Вы можете использовать файл _refuse_ для копирования отдельных категорий. Например, если вас интересуют только сообщения категории `docs`, добавьте в файл [.filename]#/usr/local/etc/cvsup/sup/refuse# footnote:[Точный путь к файлу зависит от установок *default base в вашем файле supfile.] строку
-+
-[.programlisting]
-....
-gnats/[a-ce-z]*
-....
-+ 
-Прочие примеры в этом разделе подразумевают, что вы синхронизируете только категорию `docs`.
-. Установите порт GNATS из [.filename]#ports/databases/gnats#. После установки вы обнаружите различные служебные каталоги в дереве [.filename]#$PREFIX/shared/gnats#.
-. Создайте символьные ссылки на синхронизированные каталоги GNATS в служебный каталог GNATS:
-+
-[source,shell]
+===== Полный клон
+Полный клон загружает всё дерево целиком, включая всю историю и ветки. Это самый простой способ. Он также позволяет использовать функцию Git `worktree`, чтобы все активные ветки были извлечены в отдельные каталоги, но с единственной копией репозитория.
+[source, shell]
 ....
-# cd /usr/local/shared/gnats/gnats-db
-# ln -s /usr/gnats/docs
+% git clone -o freebsd $URL -b branch [<directory>]
 ....
+-- создаст полную копию. `branch` должна быть одной из веток, перечисленных в предыдущем разделе. Если параметр `branch` не указан: будет использоваться ветка по умолчанию (`main`). Если параметр `<directory>` не указан: имя нового каталога будет соответствовать имени репозитория ([.filename]#doc#, [.filename]#ports# или [.filename]#src#).
 
-+ 
-Проделайте эту операцию для всех синхронизируемых категорий.
-. Обновите служебный файл GNATS [.filename]#categories#, расположенный в каталоге [.filename]#$PREFIX/shared/gnats/gnats-db/gnats-adm#:
-+
-[.programlisting]
-....
-# This category is mandatory
-pending:Category for faulty PRs:gnats-admin:
-#
-# FreeBSD categories
-#
-docs:Documentation Bug:freebsd-doc:
-....
-. Запустите [.filename]#$PREFIX/libexec/gnats/gen-index# для создания индекса. Вывод этой команды должен быть перенаправлен в файл [.filename]#$PREFIX/shared/gnats/gnats-db/gnats-adm/index#. Эту операцию можно выполнять периодически при помощи man:cron[8] или запускать man:cvsup[1] из скрипта, который затем сгенерирует новый индекс:
-+
-[source,shell]
-....
-# /usr/local/libexec/gnats/gen-index \
*** 15200 LINES SKIPPED ***