[devel] beehive

[Alexey Tourbin]

On Tue, Apr 10, 2007 at 02:54:51AM +0400, Hihin Ruslan wrote:
>  > > Master сгодится в таком качестве? Или Вы имеете в виду другой
>  > > формат?
>  >
>  > Да, я имел в виду что-то типа Master.
> 1 А почему именно Мастер, почему не сделать отдельный дистрибутив ?

Вы меня не поняли.  Мне отчасти всё равно, будет такой дистрибутив
выпущен или нет, тем более как он будет называться.  Я лишь говорю,
что для выпуска такого универсального дистрибутива ещё не всё готово,
тогда как для специализированных дистрибутивов это менее важно.

Вот сейчас заморожен стабильный срез сизифа.  Доподлинно известно
только, что на его основе будет выпущен серверный дистрибутив.  Пророк
Соломон сказал нам также, что на его основе будет выпущен десктопный
дистрибутив без гнома.  Я говорю, что для универсального technology
дистрибутива этот срез не подходит.  Из "моих" задач средней сложности
нужно доделать rpm-build с модульным поиском зависимостей; это можно
сделать без затягиваний.  Из общих задач большой сложности нужно
полностью перейти на сборку из git.

Что по мне, то лучше бы такого дистрибутива вообще не было.  Не надо
баловать разработчиков, пусть работают на сизифе.  Сервер и десктоп --
это решения для админов и для юзеров.  Это понятно.

> 2 А нельзя сделать для него отдельный бренч, что-бы на нём вначале 
> обкатать вопросы сборки, что-бы после разморозки от него уже расти 
> размороженному Сизифу ?

Гипотетически можно сделать что угодно.  Вопросы обкатки не тривиальны,
поэтому всякие смелые, но не обременительные, инициативы обычно (по факту)
идут по лесу.

У меня есть некоторые мысли, что же обкатка на самом деле может из себя
представлять.  Они касаются того, что beehive может работать в режиме
реального времени.  При наличии достаточных мощностей при прохождении
любого пакета в сизиф можно попробовать сделать полную пересборку сизифа.
Если пакет ломает сборку каких-либо других пакетов, он ставится на
подтверждение (подтвердить может incominger, ldv или, допустим, кто-то
ещё из ограниченного круга).  В противном случае пакет автоматически
проходит в сизиф, и очередь продвигается.

На самом деле нужно пересобирать на весь сизиф, а только ту его часть,
которая сборочно зависит от нового пакета (и всех его подпакетов).  Год
назад я написал прототип такой системы, часть её сохранилась в виде
файла buildlog.sh в qa-robot.git.  Имея на руках логи предыдущих сборок,
нетрудно построить соответствие между src.rpm'ами и собранными пакетами.
То есть можно узнать, для каких пакетов меняется сборочная среда после
прохождения в сизиф данного пакета.

С учетом полного переноса сборки на git (т.е. отказа от src.rpm пакетов)
не всё из сказанного остается актуальным.  Тем не менее, эта идея в целом
по-прежнему кажется мне правильной.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20070410/5eeb71fc/attachment-0001.bin>