Собирается ли свободное сообщество использовать для обновления своих пакетов огромных управляемых человекоподобных роботов?

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

Крибле! Крабле! Бумс…

• История полуавтоматизации: cc → make → autotools → пакеты и спецификации → сборочницы
• Хранилища и инструменты по упрощению сборки и публикации в них

Человек не должен работать!

Пакетов много, сопровождающий один. Как укоротить путь от Upstream до пакета?

• Создаваемый с нуля пакет снабжается простой спецификацией, которая может быть достроена до сложной (зависимости, сборочные зависимости, триггеры и т. п.)
• Upstream предоставляет спецификацию по которой можно собрать пакет (.spec, .egg, .gem и т. п.)
• Внешний репозиторий предоставляет спецификацию по которой можно собрать пакет

• Пакет предыдущей версии уже собран в хранилище, надо обновить

— что можно доверить роботам?

• Отслеживание новых версий: алгоритм получения версии из Upstream
• Обновление актуальных версий новыми: алгоритм обновления исходников и спецификаций
• Сборка обновлённых версий: формальная проверка успешности сборки
• Публикация обновлённых пакетов: обязательное подтверждение со стороны сопровождающего
• Оповещение заинтересованных обо всех этих событиях

В результате время сопровождающего тратится только на содержательную правки и тестирование

Двигатели прогресса

Пакетов ещё больше, сопровождающий ещё более один:

• Fedora: cnucnu

• Debian: Uscan, QA/watch, quilt/uupdate

• ALT: Cronbuild, Fedora Import

Пролегомены к идеальному сообществу роботов

Диаграмма состояний пакета:

Ещё одно изолированное состояние: вечно свежий.

Состояния неуспеха обрабатываются сопровождающим пакет (возможно, потребуется воспроизвести действия роботов и/или синхронизоваться со сборочной веткой).

Сравнить версии

Не меняет дерево исходников; возможно, и не требует его.

1. Получить версию в целевом репозитории V_t

2. Получить версии в development-репозиториях V_d1 … V_dN

3. Получить версию в upstream V_u

   • Upstream исчез, сменил формат хранения и т. п.

Версия V_di в development-репозитории может быть выше актуальной V_t, это признак ручной сборки

Допуск к обновлению при условии V_u > max(V_t, V_d1, … , V_dN)

Обновить

1. Получение актуальных исходников:
   1. Pull из целевого репозитория
   2. Pull из development-репозиториев
2. Получение Upsream-исходников

   • Upstream исходники не отдал, ошибка скачивания и т. п.

3. Формирование сборочной ветки
   1. Обновление старых исходников новыми

      • Скрипты обновления не справились с задачей, вместо upstream скачался мусор и т. п.

   2. Модификация служебных файлов (*.spec, .gear/* …)

      • Скрипты обновления не справились с задачей, информация о новом пакете неверна и т. п.

   3. Оформление коммита

Допуск к сборке

Собрать

Не меняет дерево исходников.

1. Тестовая сборка сборочной ветки в целевое хранилище
2. Получение журнала сборки

   • Старым способом не собирается, плохо обновился spec и т. п.

   • Пострадало качество сборки: unpackaged files, предупреждения и т. п.

3. Формирование бинарного хранилища для тестирования
4. Формальное тестирование

   • Пакет на устанавливается, не прошли дополнительные тесты

Допуск к проверке

Проверить

Проверяет человек (тестер), достаточно доступа к тестовому хранилищу

1. Подключение тестового хранилища
2. Установка и тестирование пакетов

   • Тест не прошёл

Допуск к публикации

Критика идеального сообщества роботов

• Асинхронный переход из состояния в состояние: push? pull?
• Shared task?
• Устаревание системы слежения за Upstream
  • tarball старый, перешли на git, на другой сайт и т. п.
  • изменение формата доступа массового Upstream (sf.net, googlecode, github, …)
• …

Дешёвая пластиковая имитация

• Полуавтоматика

  • 00-state — вывод состояния (git status и grep по журналу последней массовой сборки)

  • 01-getall — получение из g.a:people/george новых пакетов, содержащих .gear/autobuild.watch в ветке Sisyphus

  • 10-sync — синхронизация исходников с g.a:gears и g.a:people/george

  • 20-build — попытка обновления и пересборки (в случае неудачи восстанавливается предыдущее состояние, ошибки доступны в журнале)

  • 30-push — отправка в хранилище, создание подписанного тега и отправка на сборку в Sisyphus всех пакетов, имеющих статус ahead of 'origin/master'

• Сопуствтующние утилиты

Сборка происходит локально, соответствующее хранилище добавлено в системный sources.list, поэтому достаточно между 20-build и 30-push сделать dist-upgrade, чтобы начать тестировать собранные пакеты.

Accidental features

• Разделение на тестера и сборщика
• Автоматизация каждого процесса (в т. ч. тестировния)
• Унификация spec-файлов
• Сводный ресурс по актуальности пакетов
• …