22.8.1 Applying for Commit Access

When you deem it necessary, consider applying for commit access by following these steps:

1. Найдите трех коммиттеров, которые поручаются за вас. Вы можете просмотреть список коммиттеров по адресу https://savannah.gnu.org/project/memberlist.php?group=guix. Каждый из них должен отправить заявление по электронной почте на адрес guix-maintainers@gnu.org (личный псевдоним коллектива сопровождающих), подписанный ключом OpenPGP.

   Ожидается, что коммиттеры взаимодействовали с вами как c участником и могли судить, достаточно ли вы знакомы с проектом. Это не суждение о ценности вашей работы, поэтому отказ следует скорее интерпретировать как «давайте попробуем позже».

2. Отправьте guix-keepers@gnu.org сообщение с указанием ваших намерений, перечисляя трех коммиттеров, поддерживающих вашу заявку, подписанных ключом OpenPGP, который вы будете использовать для подписания коммитов, и указав свой отпечаток (смотри ниже). Ознакомся с https://emailselfdefense.fsf.org/ru/, чтобы познакомиться с криптографией с открытым ключом с помощью GnuPG.

   Настройте GnuPG так, чтобы он никогда не использовал хэш-алгоритм SHA1 для цифровых подписей, который, как известно, небезопасен с 2019 года. Например, добавив следующую строку в ~/.gnupg/gpg.conf (see GPG Esoteric Options in The GNU Privacy Guard Manual):

   digest-algo sha512
   

3. Маинтайнеры решают, предоставлять ли вам доступ к коммитам, обычно следуя рекомендациям ваших рефералов.
4. Получив доступ, пожалуйста, отправьте сообщение на адрес guix-devel@gnu.org, чтобы снова подписать его ключом OpenPGP, который вы будете использовать для подписания коммитов (сделайте это перед отправкой первого коммита). Таким образом, каждый может заметить и убедиться, что это ваш ключ OpenPGP.

   Важно: Перед тем, как вы отправите изменения впервые, сопровождающие должны:

   1. добавить ваш OpenPGP ключ в keyring ветку;
   2. добавьте отпечаток вашего OpenPGP ключа в .guix-authorizations файл ветки (-ок), которые вы подпишите (commit).

5. Обязательно прочтите остальную часть этого раздела!

Примечание: Маинтейнеры с радостью предоставят доступ к коммитам людям, которые внесли свой вклад в течение некоторого времени и имеют послужной список - не стесняйтесь и не недооценивайте свою работу!

Тем не менее, обратите внимание, что проект работает над созданием более автоматизированной системы проверки и объединения исправлений, что, как следствие, может привести к тому, что у нас будет меньше людей, имеющих доступ к главному репозиторию. Будьте на связи!

Все коммиты, которые передаются в центральный репозиторий в Саванне, должны быть подписаны ключом OpenPGP, а открытый ключ должен быть загружен в вашу учетную запись пользователя на Саванне и на серверы открытых ключей, такие как keys.openpgp.org. Чтобы настроить Git для автоматической подписи коммитов, запустите:

git config commit.gpgsign true

# Substitute the fingerprint of your public PGP key.
git config user.signingkey CABBA6EA1DC0FF33

To check that commits are signed with correct key, use:

make authenticate

You can prevent yourself from accidentally pushing unsigned or signed with the wrong key commits to Savannah by using the pre-push Git hook located at etc/git/pre-push:

cp etc/git/pre-push .git/hooks/pre-push

It additionally calls make check-channel-news to be sure news.scm file is correct.

22.8.2 Commit Policy

Если вы получили доступ к коммиту, пожалуйста, следуйте приведенной ниже политике (обсуждение политики может проходить по адресу guix-devel@gnu.org).

Нетривиальные патчи всегда должны публиковаться на guix-patches@gnu.org (тривиальные патчи включают исправление опечаток и т.д.). Этот список рассылки заполняет базу данных отслеживания патчей (see Отслеживание ошибок и патчей).

Для патчей, которые просто добавляют новый пакет или внсит небольшие изменения считается нормальным отправить коммит, если вы уверены (что означает, что вы успешно встроили его в настройку chroot и провели разумный аудит авторских прав и лицензий). Аналогично для обновлений пакетов, за исключением обновлений, которые вызывают много перестроений (например, обновление GnuTLS или GLib). У нас есть список рассылки для уведомлений о коммитах (guix-commits@gnu.org), так что люди могут это заметить. Перед отправкой изменений обязательно запустите git pull --rebase.

Когда вы отправляете коммит от имени кого-то другого, добавьте строку Signed-off-by в конце сообщения коммит лога—например, с git am --signoff. Это улучшает отслеживание того, кто что сделал.

При добавлении новостей канала (see Writing Channel News), убедитесь, что они правильно сформированы, выполнив следующую команду прямо перед нажатием:

make check-channel-news

Для чего-либо еще, пожалуйста, отправьте сообщение на guix-patches@gnu.org и оставьте время для обзора, ничего не коммитя (see Отправка исправлений). Если вы не получили никакого ответа через две недели, и если вы уверены, что все в порядке, будь нормальным совершить коммит.

Эта последняя часть подлежит корректировке, что позволяет отдельным лицам вносить непосредственные изменения в не противоречивые изменения в тех частях, с которыми они знакомы.

22.8.3 Addressing Issues

Peer review (see Отправка исправлений) and tools such as guix lint (see Вызов guix lint) and the test suite (see Запуск набора тестов) should catch issues before they are pushed. Yet, commits that “break” functionality might occasionally go through. When that happens, there are two priorities: mitigating the impact, and understanding what happened to reduce the chance of similar incidents in the future. The responsibility for both these things primarily lies with those involved, but like everything this is a group effort.

Some issues can directly affect all users—for instance because they make guix pull fail or break core functionality, because they break major packages (at build time or run time), or because they introduce known security vulnerabilities.

The people involved in authoring, reviewing, and pushing such commit(s) should be at the forefront to mitigate their impact in a timely fashion: by pushing a followup commit to fix it (if possible), or by reverting it to leave time to come up with a proper fix, and by communicating with other developers about the problem.

If these persons are unavailable to address the issue in time, other committers are entitled to revert the commit(s), explaining in the commit log and on the mailing list what the problem was, with the goal of leaving time to the original committer, reviewer(s), and author(s) to propose a way forward.

Once the problem has been dealt with, it is the responsibility of those involved to make sure the situation is understood. If you are working to understand what happened, focus on gathering information and avoid assigning any blame. Do ask those involved to describe what happened, do not ask them to explain the situation—this would implicitly blame them, which is unhelpful. Accountability comes from a consensus about the problem, learning from it and improving processes so that it’s less likely to reoccur.

22.8.4 Commit Revocation

Чтобы уменьшить вероятность ошибок, учетные записи контрибьюторов будут удалены из проекта Guix на Savannah, а их ключи - из .guix-authorizations после 12 месяцев бездействия; они могут попросить восстановить доступ к отправке коммитов, отправив электронное письмо мэйнтейнеров, не проходя через процесс подтверждения.

Maintainers⁴³ may also revoke an individual’s commit rights, as a last resort, if cooperation with the rest of the community has caused too much friction—even within the bounds of the project’s code of conduct (see Содействие). They would only do so after public or private discussion with the individual and a clear notice. Examples of behavior that hinders cooperation and could lead to such a decision include:

• repeated violation of the commit policy stated above;
• repeated failure to take peer criticism into account;
• breaching trust through a series of grave incidents.

When maintainers resort to such a decision, they notify developers on guix-devel@gnu.org; inquiries may be sent to guix-maintainers@gnu.org. Depending on the situation, the individual may still be welcome to contribute.

22.8.5 Helping Out

И последнее: проект продолжает двигаться вперед, потому что коммиттеры не только вносят свои собственные потрясающие изменения, но также уделяют свое время на reviewing и продвижение изменений других людей. Как коммиттер, вы можете использовать свой опыт и передавать права, чтобы помочь и другим участникам!