Отправка исправлений (Руководство по GNU Guix)

22.10 Отправка исправлений

Разработка проводится в системе управления версиями Git. Таким образом, доступ к репозиторию не обязателен. Мы приветствуем вклады в разработку в виде патчей, которые производит git format-patch, отправленные в рассылку guix-patches@gnu.org (see Submitting patches to a project in Git User Manual). Участникам рекомендуется потратить пару минут, чтобы установить некоторые настройки репозитория Git (see Конфигурирование Git), что может улучшить читаемость патчей. Опытные разработчики Guix, возможно, также захотят взглянуть на раздел о доступе к коммитам (see Доступ к коммитам).

This mailing list is backed by a Debbugs instance, which allows us to keep track of submissions (see Отслеживание ошибок и изменений). Each message sent to that mailing list gets a new tracking number assigned; people can then follow up on the submission by sending email to ISSUE_NUMBER@debbugs.gnu.org, where ISSUE_NUMBER is the tracking number (see Отправка пакета исправлений).

Пожалуйста, пишите логи коммита в формате ChangeLog (see Change Logs in GNU Coding Standards); для примеров загляните в историю коммитов.

Вы можете помочь сделать процесс рассмотрения более эффективным и увеличить вероятность того, что ваш патч будет быстро рассмотрен, описав контекст вашего патча и влияние, которое вы ожидаете от него. Например, если ваш патч исправляет что-то сломанное, опишите проблему и то, как ваш патч ее устраняет. Расскажите, как вы протестировали свой патч. Придется ли пользователям кода, измененного вашим патчем, вносить какие-либо изменения в свой рабочий процесс? Если да, расскажите, как. В целом, постарайтесь представить, какие вопросы задаст рецензент, и ответьте на них заранее.

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

Если авторы пакета программного обеспечения предоставляют криптографическую подпись для архива релиза, не поленитесь проверить подлинность архива. Для файла отделённой GPG-подписи это можно сделать командой gpg --verify.
Потратьте немного времени, чтобы предоставить адекватное краткое описание и полное описание пакета. Смотрите See Краткие обзоры и описания для подробностей.
Запустите guix lint package, где package - это имя нового или изменённого пакета, и устраните любые ошибки из отчёта (see Вызов guix lint).
Запустите guix style package для проверки нового определения пакетов в соответствии с соглашениями проекта (see Invoking guix style).
Убедитесь, что пакет собирается на вашей платформе, используя guix build package.
Мы рекомендуем вам также попробовать собрать пакет на других поддерживаемых платформах. Поскольку у вас может не быть доступа к реальным аппаратным платформам, мы рекомендуем использовать qemu-binfmt-service-type, чтобы эмулировать их. Для того, чтобы включить эмуляцию, добавьте модуль сервиса virtualization и следующий сервис в список сервисов operating-system в вашей конфигурации:
```
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64"))))
```
После этого запустите переконфигурирование системы.

Теперь вы можете собирать пакеты под различные платформы, обозначив опцию --system. Например, чтобы собрать пакет "hello" для архитектур armhf, aarch64, или mips64 вы должны выполнить следующие команды, соответственно:
```
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
```
Убедитесь, что пакет не использует встроенные копии программ, которые уже доступны в отдельных пакетах.
Иногда пакеты включают копии исходных кодов своих зависимостей, исходя из удобства для пользователей. Однако как дистрибутив, мы должны убедиться, что подобные пакеты в конечном итоге используют копию, которую мы уже имеем в дистрибутиве, если таковая имеется. Это улучшает использование ресурсов (зависимость собирается и сохраняется лишь один раз) и позволяет дистрибутиву производить поперечные изменения, как например, применение обновлений безопасности для поставляемого пакета программного обеспечения в единственном месте, и эти изменения будут иметь силу во всей системе — встроенные в пакет копии этому мешают.
Take a look at the profile reported by guix size (see Вызов guix size). This will allow you to notice references to other packages unwillingly retained. It may also help determine whether to split the package (see Пакеты со множественным выходом), and which optional dependencies should be used. In particular, avoid adding texlive as a dependency: because of its extreme size, use texlive-updmap.cfg procedure instead.
Check that dependent packages (if applicable) are not affected by the change; guix refresh --list-dependent package will help you do that (see Вызов guix refresh).
Проверьте, является ли процесс сборки пакета детеминистическим. Это обычно означает необходимость проверки того, что независимая сборка пакета производит точно такой же результат, которым вы располагаете, бит к биту.
Простой способ выполнить это - собрать такой же пакет несколько раз подряд на вашей машине (see Запуск guix build):
```
guix build --rounds=2 my-package
```
Этого достаточно, чтобы отловить привычный набор проблем, нарушающих детерминизм, как например, отпечаток времени или случайно генерируемый выход на результате сборке.

Другой способ — использовать guix challenge (see Вызов guix challenge). Можно запустить это один раз, когда коммит пакета был отправлен, и собрать с помощью bordeaux.guix.gnu.org, чтобы проверить, что это даёт результат такой же, как у вас. Ещё лучше найти другую машину, на которой можно собрать это и выполнить guix publish. Так как другая удалённая машина дл сборки отличается от вашей, это может выявить проблемы, нарушающие детерминизм, связанные с аппаратным обеспечением, то есть вызванные использованием различных расширений ассемблера или другого ядра операционной системы, то есть касательно файлов uname или /proc.
При написании документации, пожалуйста, используйте нейтральную по гендеру лексику, когда речь идёт о людях, как например, тут singular "they", "their", "them" и т.д.
Проверьте, что ваш патч содержит изменения, связанные только с одной темой. Связывая вместе изменения, касающиеся различных тем, делает обзор сложным и медленным.
Примеры несвязанных изменений включают, в том числе, добавление некоторых пакетов или обновление пакета вместе с исправлениями в этом пакете.
Пожалуйста, следуйте нашим правилам форматирования кода, по возможности запуская скрипт guix style, который сделает это автоматически (see Форматирование кода).
Если это возможно, используйте зеркала при указании URL исходников (see Вызов guix download). Используйте надёжные URL’ы, а не сгенерированные. Например, архивы GitHub не являются идентичными между поколениями, так что в этом случае часто лучше клонировать репозиторий. Не используйте поле name в URL, это не очень удобно: если имя изменится, тогда URL будет неправильным.
Проверьте, собирается ли Guix (see Сборка из Git), и устраните предупреждения, особенно те, которые касаются использования неопределенных символов.
Убедитесь, что ваши изменения не ломают Guix и имитируйте guix pull через:
```
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
```

При публикации патча в рассылке, используйте ‘[PATCH] …’ в теме письма. Если ваш патч должен быть применён на ветке отличной от master, допустим core-updates, укажите её в теме как ‘[PATCH core-updates] …’.

You may use your email client, the git send-email command (see Отправка пакета исправлений) or the mumi send-email command (see Debbugs User Interfaces). We prefer to get patches in plain text messages, either inline or as MIME attachments. You are advised to pay attention if your email client changes anything like line breaks or indentation which could potentially break the patches.

Когда отправите свой самый первый патч на guix-patches@gnu.org, ожидайте некоторой задержки. Вам нужно подождать, пока вы не получите подтверждение с присвоенным номером отслеживания. Дальнейшие подтверждения не следует откладывать.

Когда баг исправлен, пожалуйста, закройте тему, отправив сообщение на ISSUE_NUMBER-done@debbugs.gnu.org.