Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]
Разработка проводится в системе управления версиями Git. Таким образом,
доступ к репозиторию не обязателен. Мы приветствуем вклады в разработку в
виде патчей, которые производит git format-patch
, отправленные в
рассылку guix-patches@gnu.org (see Submitting patches to a
project in Git User Manual). Участникам рекомендуется потратить пару
минут, чтобы установить некоторые настройки репозитория Git
(see Конфигурирование Git), что может улучшить читаемость патчей. Опытные
разработчики Guix, возможно, также захотят взглянуть на раздел о доступе к
коммитам (see Доступ к коммитам).
Эта рассылка работает на платформе Debbugs, что позволяет нам отслеживать
присылаемые патчи (see Отслеживание ошибок и патчей). Каждому сообщению,
отправленному в эту рассылку, присваивается новый номер трекинга. Это
позволяет пользователям общаться о конкретном патче, отправляя электронные
письма на адрес ISSUE_NUMBER@debbugs.gnu.org
, где
ISSUE_NUMBER — это номер трекинга (see Отправка пакета исправлений).
Пожалуйста, пишите логи коммита в формате ChangeLog (see Change Logs in GNU Coding Standards); для примеров загляните в историю коммитов.
Вы можете помочь сделать процесс рассмотрения более эффективным и увеличить вероятность того, что ваш патч будет быстро рассмотрен, описав контекст вашего патча и влияние, которое вы ожидаете от него. Например, если ваш патч исправляет что-то сломанное, опишите проблему и то, как ваш патч ее устраняет. Расскажите, как вы протестировали свой патч. Придется ли пользователям кода, измененного вашим патчем, вносить какие-либо изменения в свой рабочий процесс? Если да, расскажите, как. В целом, постарайтесь представить, какие вопросы задаст рецензент, и ответьте на них заранее.
Перед отправкой патча, который добавляет или изменяет описание пакета, пожалуйста, выполните следующие проверки:
gpg --verify
.
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
Иногда пакеты включают копии исходных кодов своих зависимостей, исходя из удобства для пользователей. Однако как дистрибутив, мы должны убедиться, что подобные пакеты в конечном итоге используют копию, которую мы уже имеем в дистрибутиве, если таковая имеется. Это улучшает использование ресурсов (зависимость собирается и сохраняется лишь один раз) и позволяет дистрибутиву производить поперечные изменения, как например, применение обновлений безопасности для поставляемого пакета программного обеспечения в единственном месте, и эти изменения будут иметь силу во всей системе — встроенные в пакет копии этому мешают.
guix size
(see Вызов guix size
). Это
позволит найти связь с другими пакетами, сохранившуюся без
необходимости. Это также позволяет решить, как разделить пакет
(see Пакеты со множественным выходом) и какие должны использоваться
опциональные зависимости. В частности, это способ избежать использование
большого texlive
как зависимости и использовать texlive-tiny
или texlive-union
вместо него.
guix refresh --list-dependent package
поможет вам сделать это (see Вызов guix refresh
).
В зависимости от числа пакетов зависимостей и, как следствие, числа вызываемых пересборок, коммиты отправляются в разные ветки следующим образом:
Ветка master
(не разрушающие изменения).
Ветка staging
(не разрушающие изменения). Эта ветка предназначена для
включения в master
каждые 3 недели (примерно). Тематические изменения
(т.е. обновление стека GNOME) могут отправляться в специальную ветку,
скажем, gnome-updates
.
Ветка core-updates
(может включать главные и потенциально
разрушительные изменения). Эта ветка предназначена для включения в
master
каждые 2,5 месяца примерно.
Все эти веткиhttps://ci.guix.gnu.org размещаются на ферме
сборки и включаются в master
после первой удачной сборки. Это
позволяет нам исправлять проблемы перед тем, как они дойдут до
пользователей, и сократить окно, в течение которого собранные бинарники не
доступны.
Когда мы решим начать сборку веток staging
или core-updates
,
они будут форкнуты (forked) и переименованы с суффиксом -frozen
,
после чего замороженные ветки будут получать только исправления ошибок.
Ветки core-updates
и staging
остануться открыты для патчей в
следующем цикле. Если вы не знаете, где разместить патч, спросите в списке
рассылки или в IRC.
Простой способ выполнить это - собрать такой же пакет несколько раз подряд
на вашей машине (see Запуск guix build
):
guix build --rounds=2 my-package
Этого достаточно, чтобы отловить привычный набор проблем, нарушающих детерминизм, как например, отпечаток времени или случайно генерируемый выход на результате сборке.
Другой способ — использовать guix challenge
(see Вызов guix challenge
). Можно запустить это один раз, когда коммит пакета был
отправлен, и собрать с помощью ci.guix.gnu.org
, чтобы
проверить, что это даёт результат такой же, как у вас. Ещё лучше найти
другую машину, на которой можно собрать это и выполнить guix
publish
. Так как другая удалённая машина дл сборки отличается от вашей, это
может выявить проблемы, нарушающие детерминизм, связанные с аппаратным
обеспечением, то есть вызванные использованием различных расширений
ассемблера или другого ядра операционной системы, то есть касательно файлов
uname
или /proc.
Примеры несвязанных изменений включают, в том числе, добавление некоторых пакетов или обновление пакета вместе с исправлениями в этом пакете.
guix style
, который сделает это автоматически
(see Форматирование кода).
guix download
). Используйте надёжные URL’ы, а не
сгенерированные. Например, архивы GitHub не являются идентичными между
поколениями, так что в этом случае часто лучше клонировать репозиторий. Не
используйте поле name
в URL, это не очень удобно: если имя
изменится, тогда URL будет неправильным.
guix pull
через:
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
При публикации патча в рассылке, используйте ‘[PATCH] …’ в теме
письма. Если ваш патч должен быть применён на ветке отличной от
master
, допустим core-updates
, укажите её в теме как
‘[PATCH core-updates] …’.
Можно пользоваться почтовым клиентом или командой git send-email
(see Отправка пакета исправлений). Мы предпочитаем получать патчи в виде
простых текстовых сообщений внутри текста или отдельным вложением
MIME. Рекомендуется уделять внимание вопросу, не изменяет ли почтовый клиент
что-либо как символы новой строки или отступы, так как это потенциально
может нарушить код патча.
Когда отправите свой самый первый патч на guix-patches@gnu.org, ожидайте некоторой задержки. Вам нужно подождать, пока вы не получите подтверждение с присвоенным номером отслеживания. Дальнейшие подтверждения не следует откладывать.
Когда баг исправлен, пожалуйста, закройте тему, отправив сообщение на ISSUE_NUMBER-done@debbugs.gnu.org.
Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]