Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]
Development is done using the Git distributed version control system. Thus,
access to the repository is not strictly necessary. We welcome
contributions in the form of patches as produced by git format-patch
sent to the guix-patches@gnu.org mailing list (see Submitting
patches to a project in Git User Manual). Contributors are encouraged
to take a moment to set some Git repository options (see Конфигурирование Git) first, which can improve the readability of patches. Seasoned Guix
developers may also want to look at the section on commit access
(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 --verify
.
guix lint package
, где package - это имя нового
изменённого пакета, и устраните любые ошибки из отчёта (see Вызов guix lint
).
guix style package
to format the new package definition
according to the project’s conventions (see Invoking guix style
).
guix
build package
.
qemu-binfmt-service-type
to emulate them. In
order to enable it, add the virtualization
service module and the
following service to the list of services in your operating-system
configuration:
(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
will help you do that (see Вызов guix refresh
).
В зависимости от числа пакетов зависимостей и, как следствие, числа вызываемых пересборок, коммиты отправляются в разные бренчи следующим образом:
бренч master
(не разрушающие изменения).
бренч staging
(не разрушающие изменения). Этот бренч предназначен для
включения в master
каждые 3 недели (примерно). Тематические изменения
(т.е. обновление стека GNOME) могут отправляться в специальный бренч,
скажем, gnome-updates
.
бренч core-updates
(может включать главные и потенциально
разрушительные изменения). Этот бренч предназначен для включения в
master
каждые 2,5 месяца примерно.
All these branches are tracked by
our build farm and merged into master
once everything has been
successfully built. This allows us to fix issues before they hit users, and
to reduce the window during which pre-built binaries are not available.
Когда мы решим начать сборку веток 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
script to do that automatically for you (see Форматирование кода).
guix download
). Используйте надёжные URL’ы, а не
сгенерированные. Например, архивы GitHub не являются идентичными между
поколениями, так что в этом случае часто лучше клонировать репозиторий. Не
используйте поле name
в URL, это не очень удобно: если имя
изменится, тогда URL будет неправильным.
guix pull
вместе с:
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
When posting a patch to the mailing list, use ‘[PATCH] …’ as a
subject, if your patch is to be applied on a branch other than
master
, say core-updates
, specify it in the subject like
‘[PATCH core-updates] …’.
You may use your email client or the git send-email
command
(see Отправка пакета исправлений). 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, ожидайте некоторой задержки. Вам нужно подождать, пока вы не получите подтверждение с присвоенным номером отслеживания. Дальнейшие подтверждения не следует откладывать.
When a bug is resolved, please close the thread by sending an email to ISSUE_NUMBER-done@debbugs.gnu.org.
Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]