6676
Комментарий:
|
9062
|
Удаления помечены так. | Добавления помечены так. |
Строка 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
- Обновление актуальных версий новыми: алгоритм обновления исходников и спецификаций
- Сборка обновлённых версий: формальная проверка успешности сборки
- Публикация обновлённых пакетов: обязательное подтверждение со стороны сопровождающего
- Оповещение заинтересованных обо всех этих событиях
В результате время сопровождающего тратится только на содержательную правки и тестирование
Двигатели прогресса
Fedora: cnucnu
Debian: Uscan, QA/watch, quilt/uupdate
ALT: Cronbuild, Fedora Import
Пролегомены к идеальному сообществу роботов
Диаграмма состояний пакета:
Ещё одно изолированное состояние: вечно свежий.
Сравнить версии
Не меняет дерево исходников.
Получить версию в целевом репозитории Vt
Получить версии в development-репозиториях Vd1 … VdN
Получить версию в upstream Vu
Upstream исчез, сменил формат хранения и т. п.
Версия Vdi в development-репозитории может быть выше актуальной Vt, это признак ручной сборки
Допуск к обновлению при условии Vu > max(Vt, Vd1, … , VdN)
Обновить
- Получение актуальных исходников:
- Pull из целевого репозитория
- Pull из development-репозиториев
- Получение Upsream-исходников
Upstream исходники не отдал, ошибка скачивания и т. п.
- Формирование сборочной ветки
- Обновление старых исходников новыми
Скрипты обновления не справились с задачей, вместо upstream скачался мусор и т. п.
- Модификация служебных файлов (*.spec, .gear/* …)
Скрипты обновления не справились с задачей, информация о новом пакете неверна и т. п.
- Оформление коммита
- Обновление старых исходников новыми
Допуск к сборке
Собрать
- Тестовая сборка сборочной ветки в целевое хранилище
- Получение журнала сборки
Старым способом не собирается, плохо обновился spec и т. п.
Пострадало качество сборки: unpackaged files, предупреждения и т. п.
- Формирование бинарного хранилища для тестирования
- Формальное тестирование
Пакет на устанавливается, не прошли дополнительные тесты
Допуск к проверке
Проверить
Проверяет человек (тестер)
- Подключение тестового хранилища
- Установка и тестирование пакетов
Тест не прошёл
Допуск к публикации
Критика идеального сообщества роботов
- Асинхронный переход из состояния в состояние: 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-файлов
- Сводный ресурс по актуальности пакетов
- …