Различия между версиями 12 и 13
Версия 12 от 2011-07-24 21:59:14
Размер: 9878
Редактор: FrBrGeorge
Комментарий:
Версия 13 от 2011-07-24 22:00:49
Размер: 9972
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 31: Строка 31:
Пакетов ещё больше, сопровождающий ещё более один:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PackageWorkflow.png

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

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

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

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

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

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

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

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

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

Допуск к обновлению при условии Vu > max(Vt, Vd1, … , VdN)

Обновить

  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-файлов
  • Сводный ресурс по актуальности пакетов

FrBrGeorge/HumanlikeRobots/Paper (последним исправлял пользователь FrBrGeorge 2011-07-24 22:04:07)