22.14.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:

guix git authenticate

See Сборка из Git for running the first authentication of a Guix checkout.

Чтобы избежать случайной отправки неподписанных или подписанных неверным ключом коммитов в Savannah, обязательно настройте Git согласно See Конфигурирование Git.

22.14.2 Commit Policy

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

Ensure you’re aware of how the changes should be handled (see Managing Patches and Branches) prior to being pushed to the repository, especially for the master branch.

If you’re committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes, up to one month for changes such as removing a package—see Package Removal) after you send them for review. After this, if no one else is available to review them and if you’re confident about the changes, it’s OK to commit.

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

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

make check-channel-news

22.14.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.14.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.14.5 Helping Out

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