Next: , Previous: , Up: Содействие   [Contents][Index]

22.8 Доступ к коммитам

Everyone can contribute to Guix without having commit access (see Отправка исправлений). However, for frequent contributors, having write access to the repository can be convenient. As a rule of thumb, a contributor should have accumulated fifty (50) reviewed commits to be considered as a committer and have sustained their activity in the project for at least 6 months. This ensures enough interactions with the contributor, which is essential for mentoring and assessing whether they are ready to become a committer. Commit access should not be thought of as a “badge of honor” but rather as a responsibility a contributor is willing to take to help the project.

The following sections explain how to get commit access, how to be ready to push commits, and the policies and community expectations for commits pushed upstream.

22.8.1 Applying for Commit Access

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

  1. Найдите трех коммиттеров, которые поручаются за вас. Вы можете просмотреть список коммиттеров по адресу Каждый из них должен отправить заявление по электронной почте на адрес (личный псевдоним коллектива сопровождающих), подписанный ключом OpenPGP.

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

  2. Отправьте сообщение с указанием ваших намерений, перечисляя трех коммиттеров, поддерживающих вашу заявку, подписанных ключом OpenPGP, который вы будете использовать для подписания коммитов, и указав свой отпечаток (смотри ниже). Ознакомся с, чтобы познакомиться с криптографией с открытым ключом с помощью GnuPG.

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

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

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

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

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

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

Все коммиты, которые передаются в центральный репозиторий в Саванне, должны быть подписаны ключом OpenPGP, а открытый ключ должен быть загружен в вашу учетную запись пользователя на Саванне и на серверы открытых ключей, такие как Чтобы настроить 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

Если вы получили доступ к коммиту, пожалуйста, следуйте приведенной ниже политике (обсуждение политики может проходить по адресу

Changes should be posted to This mailing list fills the patch-tracking database (see Отслеживание ошибок и патчей). It also allows patches to be picked up and tested by the quality assurance tooling; the result of that testing eventually shows up on the dashboard at ‘’, where ISSUE_NUMBER is the number assigned by the issue tracker. Leave time for a review, without committing anything (see Отправка исправлений). If you didn’t receive any reply after one week (two weeks for more significant changes), and if you’re confident, it’s OK to commit.

As an exception, some changes considered “trivial” or “obvious” may be pushed directly. This includes changes to fix typos and reverting commits that caused immediate problems. This is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with.

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

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

make check-channel-news

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 месяцев бездействия; они могут попросить восстановить доступ к отправке коммитов, отправив электронное письмо мэйнтейнеров, не проходя через процесс подтверждения.

Maintainers44 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:

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

22.8.5 Helping Out

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



See for the current list of maintainers. You can email them privately at

Next: , Previous: , Up: Содействие   [Contents][Index]