[devel] giter-factory

[Dmitry V. Levin]

On Wed, Aug 29, 2007 at 09:05:12PM +0400, Alexey Tourbin wrote:
> 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 (текущий хед мэйнлайна) и его сборка/тестирование
> проходит заново.  Если характеристики после ребейса репозитария получаются
> не хуже, чем характеристики репозитария до ребейса, то подтверждение
> считатется действительным.  В противном случае генерируется новый запрос
> на подтверждение.
> 
> Такие пироги.

Сколько у тебя уйдёт времени, чтобы всё это реализовать?


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070829/68e519ee/attachment-0001.bin>