Differences between revisions 1 and 4 (spanning 3 versions)
⇤ ← Revision 1 as of 2011-06-11 12:23:12 →
Size: 1280
Editor: FrBrGeorge
Comment:
← Revision 4 as of 2011-06-18 16:37:56 → ⇥
Size: 3528
Editor: FrBrGeorge
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
1. Импорт
 * Новых
  * настройка autobuild
  * Типовые watchfile для sf, gh, gc, g.a...
 * Подготовленных, из целевого хранилища (критерий выбора, массовость)
1. Синхронизация
 * с целевым хранилищем
 * ?с возможной devel-веткой
1. Проверка апстрима
 * универсальная, для разных схем репозитория (схему можно надумать из rules и autobuild.watch)
 * ?что умеет uscan?
1. Обновление исходников
 * универсальное, для разных схем репозитория
 * с исправлением спека, если обновление успешно
 * ?с созданием отдельной ветки
1. Сборка обновлённого пакета
 * правильный apt.conf
 * критерии успешности
 * со слиянием, если сборка успешна
1. Тестирование
 * ?маркировка тестированых
1. Отсылка в g.a и на сборку		 Общие понятия (на примере git.alt):
 Целевое хранилище:: название ветки в /gears (sisyphus)
 Пакет:: git-репозиторий на git.alt
 Схема репозитория:: способ организации на git.alt (http://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear)
 Имя пакета:: название src.rpm ( => имени репозитория в /gears)
Действия:
 * ./ автоматическое
 * {i} требуется исследование
 * <!> ''может'' закончится неуспешно (текст после <!> описывает обработку неуспеха, по умолчанию -- останов + оповещение)
 * {2} второстепенное
Общий workflow:
 1. Добавление пакета
  * Создание нового репозитория
   * настройка autobuild
   * создание минимального хранилища "версии 0"
   * стартовое обновление исходников
  * Импорт существующего репозитория
   * {2} автоматическая конвертация
  * Типовые watchfile для sf, gh, gc, g.a... ({i} * типовые репозитории?)
 1. ./ Синхронизация
  1. с целевым хранилищем
  1. {2} с devel-веткой <!> (
 1. ./ Проверка апстрима
  1. выяснение апстримной версий <!>
   * несколько исходников
   * VCS
  1. выяснение текущей версии
   * несколько исходников
  1. сравнение версий (возможно, нестрогое)
 1. ./ Обновление исходников
  1. подготовка сборочной версии старых исходников (например, создание временной ветки)
  1. получение исходников из апстрим <!>
  1. обновление старых исходников новыми <!>
  1. модификация служебных файлов (*.spec, .gear/* ...)
  1. маркировка (например, commmit + tag)
 1. ./ Сборка обновлённого пакета
  1. Тестовая сборка <!>
   * «Домашняя» (см. [[#homebrew|Инфраструктура «домашней» сборки]])
    * последовательность сборки
    * нстройка apt.conf
   * критерии успешности
  1. Втягивание маркированных исходнков
 1. Тестирование
  * {i} маркировка тестированных
 1. Отсылка в g.a и на сборку

<<Anchor(homebrew)>>
=== Инфраструктура «домашней» сборки ===
 * Запуск по cron .... TODO
 * Доступ к бинарному репозиторию
 * Подготовка apt.conf
 * ...
=== Следствия ===
 * Разделение майнтейнера на активного пользователя (тестера) и сборщика. Разумеется, лучше в одном лице, но...
 * Внешнее автоматическое тестирование

Огромные человекоподобные роботы

Workflow

Общие понятия (на примере git.alt):

Целевое хранилище
название ветки в /gears (sisyphus)
Пакет
git-репозиторий на git.alt
Схема репозитория

способ организации на git.alt (http://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear)

Имя пакета

название src.rpm ( => имени репозитория в /gears)

Действия:

  • ./ автоматическое

  • {i} требуется исследование

  • <!> может закончится неуспешно (текст после <!> описывает обработку неуспеха, по умолчанию -- останов + оповещение)

  • {2} второстепенное

Общий workflow:

  1. Добавление пакета
    • Создание нового репозитория
      • настройка autobuild
      • создание минимального хранилища "версии 0"
      • стартовое обновление исходников
    • Импорт существующего репозитория

      • {2} автоматическая конвертация

    • Типовые watchfile для sf, gh, gc, g.a... ({i} * типовые репозитории?)
  2. ./ Синхронизация
    1. с целевым хранилищем

    2. {2} с devel-веткой <!> (

  3. ./ Проверка апстрима

    1. выяснение апстримной версий <!>

      • несколько исходников
      • VCS
    2. выяснение текущей версии
      • несколько исходников
    3. сравнение версий (возможно, нестрогое)
  4. ./ Обновление исходников
    1. подготовка сборочной версии старых исходников (например, создание временной ветки)

    2. получение исходников из апстрим <!>

    3. обновление старых исходников новыми <!>

    4. модификация служебных файлов (*.spec, .gear/* ...)
    5. маркировка (например, commmit + tag)
  5. ./ Сборка обновлённого пакета

    1. Тестовая сборка <!>

    2. Втягивание маркированных исходнков
  6. Тестирование

    • {i} маркировка тестированных

  7. Отсылка в g.a и на сборку

Инфраструктура «домашней» сборки

  • Запуск по cron .... TODO
  • Доступ к бинарному репозиторию
  • Подготовка apt.conf
  • ...

Следствия

  • Разделение майнтейнера на активного пользователя (тестера) и сборщика. Разумеется, лучше в одном лице, но...
  • Внешнее автоматическое тестирование

FrBrGeorge/HumanlikeRobots (last edited 2011-07-01 16:52:11 by FrBrGeorge)