Различия между версиями 7 и 8
Версия 7 от 2011-07-24 11:23:00
Размер: 6676
Редактор: FrBrGeorge
Комментарий:
Версия 8 от 2011-07-24 12:09:06
Размер: 9062
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 12: Строка 12:
== Крибле! Крабле! Бумс... == == Крибле! Крабле! Бумс ==
Строка 14: Строка 14:
 * Хранилища и инструменты по упрощению сборки в них  * Хранилища и инструменты по упрощению сборки и публикации в них
Строка 16: Строка 16:
Пакетов много, сопровождающий один.
 * Upstream предоставляет спецификацию по которой можно собрать пакет (.spec, .egg, .gem и т. п.)
 * Внешний репозиторий предоставляет спецификацию по которой можно собрать пакет
 * (*) Пакет предыдущей версии уже собран в хранилище, надо обновить
(*) — что можно доверить роботам?
 * Отслеживание новых версий: алгоритм получения версии из Upstream
 * Обновление актуальных версий новыми: алгоритм обновления исходников и спецификаций
 * Сборка обновлённых версий: формальная проверка успешности сборки
 * Публикация обновлённых пакетов: обязательное подтверждение со стороны сопровождающего
 * Оповещение заинтересованных обо всех этих событиях
В результате время сопровождающего тратится только на содержательную правки и тестирование
Строка 18: Строка 29:
 * '''Debian''': [[http://wiki.debian.org/debian/watch|Uscan]], [[http://anonscm.debian.org/viewvc/qa/trunk/wml/watch|QA/watch]], quilt/uupdate
 * ALT '''Cronbuild'''
 * '''Debian''': [[http://wiki.debian.org/debian/watch|Uscan]], [[http://anonscm.debian.org/viewvc/qa/trunk/wml/watch|QA/watch]], [[http://www.debian.org/doc/manuals/maint-guide/update.en.html#newupstream|quilt/uupdate]]
 * '''ALT''': [[http://www.altlinux.org/Gear/cronbuild|Cronbuild]], [[http://lists.altlinux.org/pipermail/devel/2011-February/188611.html|Fedora Import]]
Строка 29: Строка 40:
 1. Получить версии в development-репозиториях V,,d1,, ... V,,dN,,  1. Получить версии в development-репозиториях V,,d1,, V,,dN,,
Строка 32: Строка 43:
Версия в development-репозиториях может быть выше актуальной, это признак ручной сборки Версия V,,di,, в development-репозитории может быть выше актуальной V,,t,,, это признак ручной сборки
Строка 34: Строка 45:
''Допуск к обновлению'' при условии V,,u,, > max(V,,t,,, V,,d1,,, ... , V,,dN,,) ''Допуск к обновлению'' при условии V,,u,, > max(V,,t,,, V,,d1,,, , V,,dN,,)
Строка 44: Строка 55:
  1. Модификация служебных файлов (*.spec, .gear/* ...)   1. Модификация служебных файлов (*.spec, .gear/* )
Строка 67: Строка 78:
 * ...  * Устаревание системы слежения за Upstream
  * tarball старый, перешли на git, на другой сайт и т. п.
  * изменение формата доступа массового Upstream (sf.net, googlecode, github, …)
 * …
Строка 76: Строка 90:
Сборка происходит локально, соответствующее хранилище добавлено в ''системный'' `sources.list`, поэтому достаточно между `20-build` и `30-push` сделать `dist-upgrade`, чтобы начать тестировать собранные пакеты.
Строка 79: Строка 94:
 * ...  * Унификация spec-файлов
 * Сводный ресурс по актуальности пакетов
 * …

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

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

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

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

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

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

  • 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, чтобы начать тестировать собранные пакеты.

?побочные эффекты

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

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