[devel] giter-factory idea

[Alexey Tourbin]

On Mon, Sep 17, 2007 at 01:32:46AM +0400, Aleksey Avdeev wrote:
> > В общем, у меня есть некоторый набор "правильных идей", он касается
> > первичного тестирования пакетов при сборке из gear.  Большая часть этих
> > идей была озвучена здесь (в списке devel@), некоторые принципиально
> > важные пояснения были в частной переписке.  Я могу продублировать
> > пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень
> > хорошо понимать, о чем идет речь.
> 
>   Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.)

Ваш стиль коммитов в git.alt не слишком обнадеживает насчет
продуктивности обдумывания.  Тем не менее.

Есть прямая аналогия между коммитами в git и прохождением пакетов
в репозитарий.

Существует "хед" репозитария.  Хед сдвигается, когда пакет проходит
в сизиф.  Перед сдвигом хеда выполняется ряд проверок.  Если проверки
отваливают, то "сдвиг хеда" невозможен, а формируется отдельный "бранч
репозитария" (который замораживается на некоторое время, пока не станет
ясно, насколько там серьезные ошибки).  В дальнейшем этот бранч либо
удаляется (если ошибки серьезные), либо происходит мёрж этого бранча
в хед (если все специфические ошибки удалось разрулить).

Короче, начать с самого примитива и закончить самым заумным мне сейчас
будет сложно.  Я приведу несколько кусков текста, которые я написал в
частной переписке.  Типа кому надо тот поймёт.

-- 

> > В схеме с подтверждением вручную очень желательно иметь идентификатор [задания]
> Что это "подтверждение вручную" ?

Это моя идея внедрения первичного тестирования в giter-factory.
Сразу публиковать пакеты на автомате нельзя.  Сейчас вроде как
подразумевается квалифицированная проверка перед подписью и публикацией,
а если пакет автоматически опубликовался, то "отозвать" его задним
числом уже нельзя.

Значит, в автоматической системе перед публикацией будет выполняться
ряд проверок.  Минимально что должно проверяться -- это целостность
репозитария при внедрении в него новых пакетов.  В частности это
unmet'ы и возможность инициализации нового билдрута.  Представляешь
что будет если пакет опубликовался и --initroot перестал работать?!

Дальше надо будет внедрять "полную пересборку сизифа", чтобы выяснить
ломают новые пакеты что-нибудь по возможности сборки или нет.

Соответственно, если обнаружена "подозрительная ситуация", то пакет
(точнее, весь task) ставится "на подтверждение вручную".  Думаю что
можно будет обнаруживать разные классы атак на целостность репозитария.
В зависимости от классификации атаки подтверждения со стороны самого
maintainer'а может быть достаточно или не достаточно (во втором случае
требуется подтверждение со стороны "авторитета", т.е. грубо говоря
ldv|legion).

Подтверждение вручную ломает всю идею сериализации.  Если task встал
на подтверждение вручную, то этот task не должен задерживать продвижение
очереди.  Соответственно, могут возникать очень нетривиальные ситуации:
что делать с подтверждением вручную, если оно пришло слишком поздно,
и фигурально выражаясь, погода изменилась и ветер дует теперь дует в
другую сторону?  Но и тут можно кое-что придумать.  В простейшем случае
можно просто перекладывать "старые" пакеты в "новый" репозитарий, но на
самом деле это никуда не годится.  Здесь помогает аналогия мёржа.  Нужно
"смёржить" старые пакеты из "бранча" (таска), который встал на
подтверждение вручную, в текущий бранч master (новый репозитарий).
Стратегии мёржа могут быть разные.  Простейшая стратегия это как раз
нормальная формализация "перекладывания пакетов".  В бранче сидит
"операция мёржа", которая активизируется при подтверждении вручную:

        rm pkg1-subpkg1-v1.i586.rpm
        rm pkg1-subpkg2-v1.i586.rpm
        rm pkg1-v1.src.rpm
        add pkg1-subpkg1-v2.i586.rpm
        add pkg1-subpkg2-v2.i586.rpm
        add pkg1-v2.src.rpm

Если все команды rm могут быть выполнены на master'е, то данный мёрж 
всё ещё возможен.  Если же мёрж невозможен, то таск отменяется.  Можно
будет делать что-то типа авто-ребейса.

Потом можно будет сделать более продвинутые стратегии мёржа,
в части уточнение возможности пересборки пакетов и т.д.

-- 

На самом деле rm и add должны выполняться с большей гранулярностью.

        rm name SVR filename
        add name SVR filename

Гранулярность в rm страхует от удаления новой сборки в которой
добавился serial.  А гранулярность add страхует от того, что пакет
с именем name но другим SVR/filename был уже добавлен.

Но это детали.  Суть в том, что в принципе "аналогия операции мёржа"
позволяет справляться с нарушением сериализации.  Очень живительная
аналогия, я когда её понял то прямо обрадовался.  То есть можно точно
определить, изменилась погода или нет.  По крайней мере на уровне
возможности "перекладывания пакетов".

-- 

> Я хочу сократить вмешательство человека до минимума.
> [...]

Я попытался раскрыть идею в соседнем письме.  Смысл как раз в том, чтобы
формализовать весь набор действий, который выполняет квалифицированный 
специалист при проверке и подписи репозитария.  То есть работы на самом
деле должно сократиться.  То что	<...делается...>
вручную или полу-автоматически при помощи каких-то скриптов, будет
преподнесено на блюдечке с голубой каёмочкой.

Более того, большую часть "подтверждений вручную" можно будет отдать
на откуп самим maintainer'ам.  Пускай сами подтверждают или отменяют,
чево они там насобирали.  Подтверждение со стороны авторитета явно
требуется только при "конфликтах".  Например я добавил в пакет perl
подпакет coreutils.  То есть может быть конфликт между двумя
maintainer'ами.  Проверка acl по src.rpm проходит, а при попытке
преложить пакеты в репозитарий ничего не получается.  Тут-то и может
потребоваться "авторитетное" подтверждение.

Если же я запаковал в perl подпакет perl-libwww, который в свою очередь
тоже висит на мне, то авторитетам вмешиваться ни к чему.

Плюс аналогичная проверка, конечно же, нужна на provides/obsolets,
чтобы не было конфликта претензий.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : http://lists.altlinux.org/pipermail/devel/attachments/20070917/3facd549/attachment.bin