Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]
Разработка завершается использованием поставляемой системы контроля версиями
Git. Доступ к репозиторию не обязателен. Мы приветствуем вклады в разработку
в виде патчей, которые производит git format-patch, отправленных в
рассылку guix-patches@gnu.org.
Для данной рассылки создаются резервные копии с помощью Debbugs, что
позволяет нам отслеживать присылаемые патчи (see Отслеживание ошибок и патчей). Каждому сообщению, отправленному в эту рассылку, присваивается
новый номер трекинга. Затем пользователи могут общаться относительно
конкретного патча, отправляя электронные письма на адрес
NNN@debbugs.gnu.org, где NNN — это номер трекинга
(see Отправка пакета исправлений).
Пожалуйста, пишите логи коммита в формате ChangeLog (see Change Logs in GNU Coding Standards); можно просмотреть историю коммитов, например.
Перед отправкой патча, который добавляет или изменяет описание пакета, пожалуйста, выполните следующие проверки:
gpg --verify.
guix lint package, где package - это имя нового
изменённого пакета, и устраните любые ошибки из отчёта (see Запуск guix lint).
guix
build package.
qemu-binfmt-service-type, чтобы эмулировать их. Чтобы обеспечить это,
добавьте следующий сервис в конфигурацию 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). 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 the texlive-tiny
package or texlive-union procedure instead.
guix refresh --list-dependent package
поможет вам сделать это (see Запуск guix refresh).
В зависимости от числа пакетов зависимостей и, как следствие, числа вызываемых пересборок, коммиты отправляются в разные бренчи следующим образом:
бренч master (не разрушающие изменения).
staging branch (non-disruptive changes). This branch is intended to
be merged in master every 6 weeks or so. Topical changes (e.g., an
update of the GNOME stack) can instead go to a specific branch (say,
gnome-updates).
core-updates branch (may include major and potentially disruptive
changes). This branch is intended to be merged in master every 6
months or so.
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.
Примеры несвязанных изменений включают, в том числе, добавление некоторых пакетов или обновление пакета вместе с исправлениями в этом пакете.
etc/indent-code.el, который сделает это
автоматически (see Форматирование кода).
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.
Когда баг исправлен, пожалуйста, закройте тему, отправив сообщение на NNN-done@debbugs.gnu.org.
При отправке набора патчей (например, используя git send-email),
отправьте сначала одно сообщение в рассылку guix-patches@gnu.org, а
затем отправьте последующие патчи по адресу
NNN@debbugs.gnu.org, чтобы они были объединены. Подробные
сведения см. в разделе Документация по Debbugs. Команду git send-email можно установить
с помощью guix install git:send-email.
Next: Отслеживание ошибок и патчей, Previous: Стиль кодирования, Up: Содействие [Contents][Index]