[devel] giter-factory

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]

On Wed, Aug 29, 2007 at 07:56:32PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote:
> [...]
> > Я посмотрел документацию legion'а к giter-factory, что-то меня это
> > нисколько не обнадёжило насчет возможности внедрения первичного
> > тестирования перед публикацией.  Скорее разочаровало.
> 
> Что именно разочаровало?

Цитата из giter-factory/doc/info.tex:

	Как только указание получено, репозиторий встаёт в очередь на
	сборку. Все запросы от разных пользователей сериализуются по
	времени.

	Процесс пересборки параллелится по архитектурам, но не по
	положению в очереди. Такой подход позволяет просто сформировать
	порядок сборки зависимых пакетов.

	После удачной пересборки пакет сразу же публикуется. Следующие
	пакеты из очереди пересобираются уже на новом публичном
	репозитории.

Это я называю "наивная сериализация".  Прошёл "очень плохой пакет"
и сразу же опубликовался, полсизифа перестало собираться; отозвать
сборку задним числом уже нельзя.

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

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

Если предусмотрена схема с подтверждением вручную, тогда вся идея
"наивной сериализаци" летит в тартарары.  Подтверждение может поступить
через час, через два или три, через день, а может и не поступить вовсе
(имплицитная отмена).  Скорость продвижения очереди не должна
зависеть от человеческого фактора, которым является продвижение вручную.
Если пакет ставится не подтверждение, то создается "временный бранч"
с "временным сизифом".  Очередь продвигается с предыдущего состояния,
то есть "коммита" в мэйнлайн не происходит.  Если приходит подтверждение
вручную, то нужно сделать "мёрж" между временным сизифом с проблемным
пакетом и текущим хедом мэйнлайна.  Получается прозрачная аналогия
с гитовскими коммитами:
	
	 /M merged pkg2 with pkg4
	* | confirmed pkg2
	| * pkg4 success
	* | pkg3 problems: please confirm
	 `* pkg2 success
	  * pkg1 success

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

Такие пироги.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]